in reply to Re^3: Error codes vs die exceptions vs ...
in thread Error codes vs die exceptions vs ...

Sorry, I should have been clearer

> > 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?

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Replies are listed 'Best First'.
Re^5: Error codes vs die exceptions vs ...
by haj (Vicar) on Jul 07, 2019 at 19:21 UTC
    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.

[reply]
Re^5: Error codes vs die exceptions vs ...
by holli (Abbot) on Jul 07, 2019 at 14:27 UTC
    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.
[reply]
[d/l]
[reply]

In Section Seekers of Perl Wisdom