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

Exceptions propagate until they are handled which may be at the outermost level by Perl handling the die. Nothing between the code throwing the exception and the node handling it sees the exception.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
  • Comment on Re^3: Error codes vs die exceptions vs ...

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

[reply]
[d/l]
[select]
      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]
      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