On Thu, Jul 25, 2013 at 8:28 AM, David E. Wheeler <david@justatheory.com> wrote: >>> Yeah, though if we went with the nested catch, it would affect the lexical scope in which it is declared, block or function. Perhaps not file, though. >> >> why not file? > > I don’t know. Off the cuff it did not seem like a great idea. But now I can think of how it might be useful for one-off scripts. I might use a CATCH block instead of END to do final cleanup of open file handles or something in the even of an error. Or just nicely formatting any error. > > So ignore my “Perhaps not file, though’ comment. :-) It would be good for catching all errors in a library. With that use case in mind, having a package catch scope might be good too, which would get checked whenever an exception happens in a named sub that lives in that package, after the file lexical scope. We'd need a way to specify that we're writing into the package scope and not the file scope, how about COLON-COLON, or just fully qualified, that way you could write them into other packages ::CATCH UNIVERSAL { say "intercepted an exception [$_] at package ".__PACKAGE__." scope"; THROW; # without argument, rethrows current exception, like C++ } main::CATCH UNIVERSAL { say "intercepted an exception [$_] at main:: package scope"; THROW; # without argument, rethrows current exception, like C++ }Thread Previous | Thread Next