in reply to Re^2: eval error stack (implementation dependent)
in thread eval error stack

With @@, there would be no need to store references to the inner exception

Of course there would be. Because I want the inner exception to be stored when it is actually part of the cause of the outer exception and not because it was an incidental exception that was thrown and handled inside of the code that later detected an error and threw the outer exception.

The current value of $@ could be pushed onto it, if $@ hasn't been accessed before resetting.

But your original example was, in part: 

    if ($@) {
        die "baz failed!\n";
    }

[download]

The first line I quoted accessed $@. So your own solution doesn't work in your own example. So you have an implementation hair to split there.

- tye        

Replies are listed 'Best First'.
Re^4: eval error stack (understood)
by shmem (Chancellor) on Nov 20, 2015 at 23:10 UTC
    So you have an implementation hair to split there.

    ...since this whole meditation is about a hair split - well, then: evaluated but not accessed ? or perhaps checked for but not read ? But then, to check it, it has to be accessed, and to evaluate it, it must have been read. Too fine this hair to split for me is. Tough beans. This would mean adding new flags to $@ - accessed, checked, read, read & passed, perhaps even read & understood... ;-)

    Thanks for your time and patience.

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]

      Yeah, several times now when I've implemented an "exception" class (sometimes in Perl, sometimes not), some of the methods are documented as marking the exception as "handled". Some of the methods mark the exception as "logged or at least doesn't need to be logged". When the exception is destroyed, if it hasn't been marked as handled, then an error is logged with a bunch of details. Otherwise, if it hasn't been logged yet, then the exception is just logged.

      If you wanted similar functionality for other things that get passed to die, then you could set up a $SIG{__DIE__} handler that would wrap non-exceptions into an exception object.

      It can still be a bit tricky to figure out, in general, whether code not following your coding standard "handled" your exception. You can use overload and detect use in a boolean context and use in a string context and decide that use in a string context means it was "handled".

      Update: Oh, and at least one time, the class also tracked if the exception was tested (used in a boolean context). If an exception is destroyed without being tested, the d'tor die()s, giving you autodie-like behavior.

      - tye        

[reply]

In Section Meditations