develooper Front page | perl.perl5.porters | Postings from July 2020

Re: Exceptions thrown from LEAVE

Thread Previous | Thread Next
Christian Millour
July 8, 2020 10:54
Re: Exceptions thrown from LEAVE
Message ID:
Le 08/07/2020 à 00:28, Paul "LeoNerd" Evans a écrit :
> On Tue, 7 Jul 2020 20:43:40 +0200
> Christian Millour <> wrote:
>> You would need a way to access this stack/history in a catch block,
>> and maybe to cook it if you dealt with some of the reported issues
>> but have to rethrow the exception (with its cooked history) to
>> another agent up the ladder to deal with the rest. System support
>> would be needed for error raised in system destructors (e.g.
>> automatic closing of lexical filehandles).
>> I have no clue as to whether this is doable, even with an EV. Might
>> be nice though.
> Well, indeed that was most of the point of having a new,
> natively-recognised representation type for exception values like this.
> Once core understands them, it can indeed annotate such extra
> information on. It becomes a simple matter of maybe
>    catch ($e) {
>      warn "something happened...";
>      if(my $caused_by = $e->caused_by) {
>        warn "which itself was caused by ...";
>      }
>    }

I was under the impression that the focus is the "EV" thread was 
primarily on backcompat with core-thrown strings, and possibly syntaxic 
sugar to help catch errors.

But the fundamental capability that is currently missing from Perl and 
the other languages you quoted is an ability to handle "multiple faults" 
without losing anything. Meaning having access to the full set of 
as-yet-undealt-with issues (exceptions) at the point of the catch. 
Options a) and b) in your list lose data. Or in the best case force you 
to have an external process monitoring stderr to detect and react to 
issues that were swept under the carpet (i.e. only warned about) in the 
main process.

The root problem is that "multiple fault" capability needs to be 
built-in in your error *raising* mechanism. Which is not the case 
currently. So die/throw for instance would need to be aware of existing 
undealt-with issues/exceptons at the time of invocation, to somehow 
chain them to the new one; at the user level, if you deal with one issue 
in a catch block but have to rethrow the rest up the ladder; at the 
language/core/system level to do the same for exception raised in 
automatic destructors (e.g. closing of a lexical filehandle).

The very syntax of die/throw might need to be extended to allow for this 

And if that ever gets done, the way you *catch* them may have to be 
rethought entirely. Because if you deal with a list/stack/chain of 
exceptions instead of a single one you have other problems than the 
exception type. How you deal with anteriority comes to mind, there are 
undoubtedly others.

So yeah, maybe an EV type would help. I do not know. Maybe a 
thread-local stack could help too. What you need first in any case is a 
"multiple fault"-capable error raising mechanism. Once you have that you 
may concentrate on catching/handling/rethrowing the faults.

True story : years ago a stockist had to pay a very hefty fine, and 
charter an helicopter, to deliver components to an assembly line that 
had stopped for want of said components (a *very* expensive 
proposition), the delivery order having been lost because of an 
incorrectly handled double error. I was not responsible but it has 
shaped the way I code and deploy my systems. Redundant belts and 
suspenders everywhere. Error handling probably accounts for more than 
half the production code I write, and half the systems I deploy are 
really monitoring and surveillance agents for the main ones.

So yeah, a solid "multiple-fault capable" error 
raising/handling/reporting system would be nice to have. I have no idea 
whether it is even doable, not to mention doable in the Perl context 
with backcompat constraints added. A worthwhile endeavour at any rate, 
what Damian Conway would likely label a SMOP ;-)

With (hopeful) regards,


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About