> On Oct 24, 2019, at 12:31 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > On Thu, 24 Oct 2019 at 16:38, Mike Schinkel <m...@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
