in reply to Re: eval error stack (noise)
in thread eval error stack

Yeah, don't do that.

Well, I certainly don't. This is a contrived example of course. Such code, if present, usually is buried inside a module chain (probably of third party modules), and if so, difficult to debug.

But, yes, you lose programmatic access to inner error(s). But if you want programmatic access to errors, then you should be using structured exceptions and you get access to the inner error by having the outer exception store a reference to the inner exception.

With @@, there would be no need to store references to the inner exception, and any code that doesn't, would do.

I agree with all your points of proper error handling, and in fact I do follow them in my coding. But the code I write just makes up for 2% of the whole code perl exercises in any program or application running on my behalf.

I don't see any way for your idea of collecting all exceptions to produce more signal than noise.

This is the case also with e.g. Carp::confess and perls backtrace facility. It is in place, but you don't need it. Except when you do.

Actually, I don't even see how such an idea ever allows for an exception to be freed. So catching an exception just becomes a memory leak.

That depends on the semantics of @@. The current value of $@ could be pushed onto it, if $@ hasn't been accessed before resetting. And it could be handled via a pragma: 

use evalerrorstack; # @@ initialized
...
no evalerrorstack; # @@ cleared

[download]

But you didn't get my point, which is: $@ is related to eval errors. Why isn't @@ ? Probably the answer is: you don't need it, it can be done otherwise, and there is a canonical way to handle (eval) errors.

Actually, the idea of using @@ comes from wanting to be able to say:

sub expand {
    my $macros = shift;
    my $result;
    @{$result}{keys %$macros} = map { eval $_ } values %$macros;
    return if @@;
    $result;
}

[download]

If a subroutine fails, I usually set $@ and just return. In the above case, there may be a bunch of failures which are all related to macro expansion, which I would like to be able to report. The above is for now written as 

sub expand {
    my $macros = shift;
    my $result;
    my @errors;
    for ( keys %$macros ) {
        $result->{$_} = eval $macros->{$_};
        push @errors, $@ if $@;
    }
    if ( @errors ) {
        $@ = join "\n", @errors;
        return;
    }
    $result;
}

[download]

but having @@ acummulate $@ would just be handy if failures occur in list context and/or $@ hasn't been accessed before it is being set again.

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

Replies are listed 'Best First'.
Re^3: eval error stack (unaccessed)
by tye (Sage) on Nov 15, 2015 at 23:30 UTC
    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        

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