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

RE: A common base exception object for Perl - RFC



With a minimal base class you gain two things. First, all exception objects
can be subclasses of Exception, permitting:
	$@->isa('Exception')
as a common handler for any exception. Secondly, the author of an Exception
subclass does not have to ever know about the '""' code. While simple
looking, it would be a large distraction for people to have to read `perldoc
overload` (or think they have to read it).

Certainly when Tom is around, 'to_string' is better than 'toString'.

You're right, it would be likely just as well if Exception implemented
$@->to_string === sub { "Base Exception" };

Exception, or some other module, may want to export a function to
conveniently hide the complexity of:
	ref $@ and ref $@ !~ /^(HASH|ARRAY|GLOB|CODE|SCALAR)$/
to permit:
	if ( blessed $@ and $@->isa(...) ) { ... }

P.S. (sorta)
	While I'm near the topic again, I'd like to comment that it would be
nice if people ceased to talk about looking in @ISA for information about
objects. Using a non-OO technique to handle objects is very limiting. Just
use the 'isa' method, and leave the details of implementation out of it. Not
all objects have an @ISA.


-----Original Message-----
From: Martyn Pearce [mailto:m.pearce@inpharmatica.co.uk]
Sent: Thursday, January 20, 2000 10:35 AM
To: Redford, John
Cc: 'Pete Jordan'; Perl5 Porters
Subject: RE: A common base exception object for Perl - RFC




Redford, John writes:
| 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.

Am I being obtuse (probably...), or does this gain us nothing?
Arbitrary items aleady get stringified --- to HASH(0xffff) or some
such.  With point 3 below, you're just stating a standard method name
for "".  I don't see how this helps us.

| 2. 'toString' instead of 'render'.

As we're on naming, to_string would be more consistent with other perl
modules.

| 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.

Supplying a simple to_string, e.g.,

sub to_string { "override me!" } would suffice hear.  Why check for the
existence of a method you might as well implement (you could of course
use your "" if you felt it better...)

Also, Pete:

> PROPOSED INTERFACE
> 
> 	use Exception qw(-stacktrace);
> 
> 	my $e=new Exception 'text';
> 
> 	my $f=new Exception -text=>'foo', -class=>'Error',
> 			-name=>'bar', -errcode=>$!, -exitcode=>23;
> 

the use of -foo for configuration items seems to me to be something
picked up from Tk and/or analogy with command-line calls.  I'm not
convinced that they help here; and I don't see them used commonly
through the non-Tk modules.

| 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 $@.

Part of the very purpose of OO implementations is to encapsulate
data-structure --- the client certainly should not be utilizing the
HASHness of a particular impl.; everything should be called via methods.

Mx.


Follow-Ups from:
Pete Jordan <pjordan1@email.mot.com>

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