I think you need also to take a look for this:

@AhmedAlaa4611 What exactly do you mean with this?

I think -but not sure- that we may need to update the corresponding one. What do you think about that?

Ah, right—thanks for the hint 👍🏻

Sorry, other question. Should we use \Closure instead of callable?

we checks if the $dontReportWhen is not an instance of the \Closure.

It looks like it accepts both Closure and other types of callable. Since Closure is a sub type of callable, it doesn't have to be explicitly mentioned. Or am I missing something?

I'm not sure to be honest, but I think they should be the same either \Closure or callable.

That would mean to revert #56435

That would mean to revert #56435

I made that because the $dontReportWhen is type hinted with \Closure.

Now, what we do is:

Illuminate\Foundation\Configuration\Exceptions::dontReportWhen takes the $dontReportWhen as a \Closure then passes it as a callable to the Illuminate\Foundation\Exceptions\Handler::dontReportWhen.

I think we need to refine them but not sure weather to use \Closure or callable

Well, technically, \Illuminate\Foundation\Exceptions\Handler::dontReportWhen() might also be independently called from somewhere else, resulting in one code path always being a Closure and one code path always being some other callable. If that was true, having Closure type hint on \Illuminate\Foundation\Configuration\Exceptions::dontReportWhen() while having callable type-hint on \Illuminate\Foundation\Exceptions\Handler::dontReportWhen() would be consequential 🤔

I agree with your technical nuance regarding the possibility of different call scenarios. Given that, I’m convinced the current state of this PR handles this appropriately.

Thanks

Thanks a lot! :)