Lack of feedback on closed PR

[DeepDiver1975]

Please re-consider my closed PR - I placed some comments to explain the reasoning which I still consider valid.

THX a lot

#1468 (comment)

[driesvints]

Taylor already explained it. That method doesn't throws the exception. Only methods that actual throw exceptions are marked with a throws annotation in Laravel.

Please don't open issues to ask these kinds of questions and try a support channel next time. I know you were looking for an answer but closed PR's are rarely looked at again and the issue tracker is only for reporting bugs with a library.

[DeepDiver1975]

Taylor already explained it. That method doesn't throws the exception. Only methods that actual throw exceptions are marked with a throws annotation in Laravel.

Which is wrong ... see withErrorHandling is throwing that exception and so issueToken should throw that exception as well.

passport/src/Http/Controllers/HandlesOAuthErrors.php

Lines 19 to 21 in ab9e204

	* @throws \Laravel\Passport\Exceptions\OAuthServerException
	*/
	protected function withErrorHandling($callback)

[DeepDiver1975]

try a support channel next time.

Will open an item in GitHub Discussions as well .....

[DeepDiver1975]

Will open an item in GitHub Discussions as well .....

laravel/framework#39365

[driesvints]

Which is wrong ... see withErrorHandling is throwing that exception and so issueToken should throw that exception as well.

You misunderstand. That method is cascading the exception that's been thrown. It doesn't actually throws the exception. Which is what I tried to explain.

[DeepDiver1975]

Regardless of the exception being thrown or cascaded the information about that exception being thrown is valuable for developers (reading the phpDoc) as well as IDEs like phpstorm.

[driesvints]

Look buddy. I feel like we're running in circles here. You seem to be really wanting to be right on this one. Everything you said above is indeed correct. The point you're missing is that we have our own coding standards which we follow. And this specific one states that we only add @throws annotations to the methods that actually throw them. Regardless of any other methods that's calling these. If we were to add @throws annotations to every method that calls a method that throws exceptions then we'd have massive docblocks throughout our libraries. That's why we don't do that.

It's our right as maintainers to tackle this in the way we deem best for the project regardless of how beneficial this change would be for you specifically. Now let this one slide and move along.

[DeepDiver1975]

The point you're missing is that we have our own coding standards which we follow. And this specific one states that we only add @throws annotations to the methods that actually throw them. Regardless of any other methods that's calling these. If we were to add @throws annotations to every method that calls a method that throws exceptions then we'd have massive docblocks throughout our libraries. That's why we don't do that.

THX buddy- that is finally an explanation one could live with. Referencing the coding style right from the beginning would have made this all easier for us all.