Re: Reclassifying some PHP functions warning as exceptions
| From: | Mike Schinkel | Date: | Thu, 24 Oct 2019 19:42:49 +0000 |
| Subject: | Re: Reclassifying some PHP functions warning as exceptions | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-107667@lists.php.net to get a copy of this message | ||
> On Oct 24, 2019, at 12:31 PM, Rowan Tommins <rowan.collins@gmail.com> wrote:
>
> On Thu, 24 Oct 2019 at 16:38, Mike Schinkel <mike@newclarity.net> wrote:
>
>>> Here, try() would swallow only FileException, other exceptions are still
>>> thrown. I'm not sure if this construct is worth introducing though, the
>>> difference compared to a proper try / catch is much smaller.
>>
>> I would want it to capture every exception. Why not?
>
> Because you might want to convert "FileLockedByAnotherProcessException" to
> a locally-handled error, but allow "ServerIsOnFireException" to bubble up
> to a higher-level exception handler. That's why catch blocks basically
> force you to specify class/interface names: you should catch only the
> exceptions you actually know how to handle in that particular piece of code.
I totally understand that, for those wanting to program with exceptions.
But if we added a try() "function", the goal of that function IMO would be to capture all
exceptions and return them as errors for those who don't want to use exceptions. But I could
just as easily has logic that says "if it is ServerOnException exception, I can throw it
again" If I want too. Or I can handle it another way.
The point it, I am asking to be put 100% in control and be able to choose how to handle errors, not
have to figure out which exceptions somethings throws because a function can throw many different
types and those types are not always well documented.If it it is returned, I will always get it,
even if my code did not expect it.
-Mike