http://qs321.pair.com?node_id=11102465


in reply to Error codes vs die exceptions vs ...

I echo choroba's suggestion that propagating errors from nested code can be cleanly solved by throwing and catching exceptions using die and eval or tools like Try::Tiny (which wraps die/eval into a nice package). There is more to it than that though. Good exception handling can make a huge difference in cleaning up error management in code. It removes the need for most code to be aware of errors. The propagation techniques that use special sauce for returning error cases from subs require every use of the sub to manage error handling. Exception handling allows error handling in localised and easily recognised places.

Full on exception handling can use an exception object that provides as much or as little of the error context as needed from an error string or code to a full dump of the call stack! As a taste consider:

use strict; use warnings; package Error; sub new { my ($class, $errorStr, @params) = @_; my @context = caller; return bless {err => $errorStr, context => \@context, params => \@ +params}, $class; } sub Dump { my ($self) = @_; my ($package, $file, $line) = @{$self->{context}}; print "Exception: Pkg $package in file '$file' at line $line: '$se +lf->{err}'\n"; } package main; eval { DoStuff(); return 1; } or do { my $err = $@; $err->Dump() if $err->isa("Error"); }; sub DoStuff { die Error->new("Something went wrong."); }

Prints:

Exception: Pkg main in file 'delme.pl' at line 32: 'Something went wro +ng.'
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Replies are listed 'Best First'.
Re^2: Error codes vs die exceptions vs ...
by LanX (Saint) on Jul 06, 2019 at 16:02 UTC
    Thanks!

    ... what I like about your approach is that you can distinguish between different exception classes ( literally so)

    > Exception handling allows error handling in localised and easily recognised places

    Well I seem to remember that exception handling needs to propagate too, if the class can't be handled locally.

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

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

Re^2: Error codes vs die exceptions vs ...
by karlgoethebier (Abbot) on Jul 06, 2019 at 12:18 UTC

    This sounds very "vernünftig". What about putting this stuff into some fancy little role? See What About Providing Constructors in Roles? for some ideas for roles providing constructors. Callow thought: May be it should be a singleton 🤪. Best regards, Karl

    P.S.: I‘m on vacation and unfortunately there is no Perl on the iPad and i don‘t like blindfold mode.

    «The Crux of the Biscuit is the Apostrophe»

    perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help