Problematic use of signal __DIE__ handlers in OIO internals

Posted on 2008-09-12 14:20:13-07 by flories

The OIO internal $SIG{__DIE__} approach, heavily used to provide proper debugging info, unfortunately seems to interfere with custom exception mechanisms, at least in occasions that have to do with object initializations. Example:

sub custom_throw { die "I'd like to throw some perl error as is, rather than one with OIO debug-info clutter: $@"; } A->new(); package A; use Object::InsideOut;{ sub _init :Init { eval { B::foo(); }; main::custom_throw() if $@; } } 1; package B; use Carp qw(croak); sub foo { croak "Threw an error for fun" };

In all, OIO is great work that fascilitates good work, but I would be glad if you find a better solution on that issue. In the meantime, one has to work-around with another "local $SIG{__DIE__};" within evals in :Init & Co. subroutines. At last, it is an ugly hack to cope with a foreign problem. Thank you, flories

Direct Responses: 8797 | Write a response

Posted on 2008-09-12 17:00:31-07 by jdhedden in response to 8796

Re: Problematic use of signal __DIE__ handlers in OIO internals

One of design philosophies of OIO was to use an object-oriented approach to error handling as suggested in Damian Conway's book "Perl Best Practices." By using Exception::Class for this, OIO is meant to work with custom exception handling.

The need for "local $SIG{'__DIE__'};" statements inside :Init, etc. subroutines is documented in the POD, but not specifically for purpose you outlined. I'll try to expand on this for the next release. Thanks.

In your example, aside from adding "local $SIG{'__DIE__'};" to the 'eval' in _init(), if you create your own Exception::Class objects, you can generate the type of behavior I think you're looking for:

#!/usr/bin/perl use strict; use warnings; package A; { use Object::InsideOut; sub _init :Init { eval { local $SIG{'__DIE__'}; B::foo(); }; main::custom_throw() if $@; } } package B; { use Carp qw(croak); sub foo { croak "Threw an error for fun" }; } package main; use Exception::Class ( 'MyBad' => { 'description' => 'Minimalist exception class', }, ); sub custom_throw { MyBad->throw( 'message' => "I'd like to throw some perl error as is, " . "rather than one with OIO debug-info clutter: $@", ); } A->new();

Hope that helps.

Direct Responses: 8800 | Write a response

Posted on 2008-09-13 20:13:44-07 by flories in response to 8797

Re: Problematic use of signal __DIE__ handlers in OIO internals

Thank you very much for your prompt response. Indeed, I did use an Exception::Class in my original script, just stripped all that off in order to expose the problem. I would assume like you that the Exception::Class should manage its instances coming from different directions and somehow merging one into another. Perhaps that class fails to treat/check $@ appropriately, but stringifies it too early when explicitly passed to the Exception thrower (in our example, that'd be pointless, hence ...). But it's just a spontaneous unverified notion. P.S.: Conway's Best Practices is like a bible for me, too. But while the (Christian) Bible is said to contain passages that pour many litres of blood, it is obvious that murderers are still a very minority, even among catholics I reckon.

Direct Responses: Write a response