RE: A common base exception object for Perl - RFC

["Redford, John" <John.Redford@fmr.com>]

WRT 3,
	sub to_string { "Base Exception" }
can work even without attributes.

WRT 5, I am trying to say that I wouldn't want to see the Exception object
tied in a bizarre way to the feature set of the Carp module. I can't imagine
a good usage of Carp-like manipulation of an Exception; simply because the
point were the Exception is raised is explicitly NOT where the logic to
handle the exception is located. What would be best is a way for:
	eval { ... die new Exception }
	if ( blessed($@) and $@->isa('Exception') ) { confess $@ }
to generate a stack dump as-if the confess occurred where the exception was
located. This would seem to require for 'die' to look at its argument,
thusly:
	sub die {
		if ( blessed($_[0]) and $_[0]->isa('Exception') {
			$_[0]->stack_data(...);		# Shove stack data
into $_[0]
		}
	}
so that the data would be preserved across arbitrary subsequent processing.
Personally, I would just not worry about it now; I'd rather see a basic
module sooner than a do-everything module-suite later.

Perhaps it would be possible for there to be yet-another special variable as
a peer to $@ containing stack information about the most recent die():
	if ( blessed($@) and $@->isa('Exception') ) {
confess_with_stack($DIE_STACK) }


-----Original Message-----
From: Pete Jordan [mailto:pjordan1@email.mot.com]
Sent: Thursday, January 20, 2000 11:25 AM
To: Perl5 Porters
Subject: Re: A common base exception object for Perl - RFC


"Redford, John" wrote:

> 1. Make the base class minimal. Do not include any special fields like
> 'name', 'errcode', or 'exitcode'. Don't include any fields or methods,
> just the '""' override.

Maybe. I'd like to see at least the standard Perl behaviour in the base
class - ie. error text, exit code and caller info. Name: OK, class could
come from the exception class as per C<Error>.

> 2. 'toString' instead of 'render'.

ACK.

> 3. Base implementation of '""' as follows:
>         sub { $_[0]->can('toString') ? $_[0]->toString() : "" };
>    Just enough to avoid errors with existing code, without requiring a
> conversion function to exist.

If the base class contains at least an error text attribute, it can have
a real stringification method, otherwise OK.

> 4. This needs to work:
>         my $e = new Exception;
>         die $e;
>    It should not be necessary to write:
>         $e->raise;

That was implicit in my initial message (if not actually stated :)

> 5. Will Carp routines behave properly? I know that 'die' will happily pass
> along a reference in $@, but won't Carp always stringify it? What would be
> the point of using a reference type which was always converted into a
> string before it could be caught?

Not much I can do about this other than patching C<Carp>. However,
equivalent functionality to C<Carp> would be available either in my base
class or in, say, C<Exception::Carp>.

> Regardless, I think it would be more
> natural to write:
>         confess $e;

Matter of style and preference. I can always put selected methods into
C<@EXPORT_OK> if the consensus is that this is a Good Thing. For myself,
I prefer object syntax.

>   Right now everyone assumes that every $@ is a string. It would be little
> improvement (for me, at least) to assume that everything in $@ is either a
> string or a HASH ref which has a field 'errcode'.
> 
> I would want to see a model which encouraged/forced subclassing of
> Exception in order to get a useful exception object, resulting in code
> like:
> 
>         if ( ref $@ and $@->isa{'MyException') ) { ... }
> 
> instead of code like:
> 
>         if ( ref $@ and $@->{class} eq 'MyException' ) { ... }

Agreed.

> The Exception object model should not preclude the use of "better" Perl
> objects which are not based on HASH refs (or pseudohashes). If common
> practice is to treat $@ as "A string or a HASH ref", it becomes impossible
> (again!) to use arbitrary reference types in $@.

Agreed again - nothing in my interface precludes non-HASH
implementations, nobody should ever access properties of an exception
object other than via methods.

Pete
-- 
use Disclaimer::Standard;	# Motorola GSM Software Factory
my $phone='+44 1793 564450';	# "'Not twisted,' Salzy once said of
my $fax='+44 1793 566918';	#  her own passion, 'it is helical.
my $mobile='+44 7973 725120';	#  That sounds better.'"

---

Follow-Ups from:

Pete Jordan <pjordan1@email.mot.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---