Re: Reclassifying some PHP functions warning as exceptions

From: 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

« previous php.internals (#107667) next »