Re^4: eval error stack (understood)

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'

Comment on Re^4: eval error stack (understood) Download Code

Replies are listed 'Best First'.

Re^5: eval error stack (class)
by tye (Sage) on Nov 21, 2015 at 01:23 UTC

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]


No such thing as a small change
	PerlMonks