> > if the class can't be handled locally.

let's say you want to catch one exception class directly but delay handling of other classes to higher scopes ...

Then you'd need to propagate the unhandled exception classes again in the first catch{...} to reach the next catch{...}

... right?

Then you'd need to propagate the unhandled exception classes

That's true for Try::Tiny. My first encounter with Perl's exceptions "beyond eval/die" was Error, which is much like Java in that it allows you to catch a particular error class, and passes all other errors on. TryCatch also does this, but I've never used it.

Error has its quirks as is clearly indicated in the module's description (section "Warnings"), and TryCatch uses the spooky Devel::Declare, so getting accustomed to propagate unhandled errors is probably a good idea.

In Perl, yes. It's different for most strongly typed languages though I believe. There an exception bubbles up the stack of error handlers until it reaches one that feels responsible for it. Or none, but then it crashes the program.


holli

You can lead your users to water, but alas, you cannot drown them.

There are Perl modules that attempt to provide such a mechanism, at least TryCatch and Syntax::Feature::Try (I only say "attempt" because I haven't tested them myself). See also Task::Kensho::Exceptions and Exception::Class.