RE: A common base exception object for Perl - RFC

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

These don't seem like problems that you need to solve in the 'Exception'
class. Let the author of a meaningful subclass worry about
internationalization when writing 'to_string'.

Inventing a second-tier of "categories" when you can just use inheritance
structure, and the addition of "special" methods seems needless & confusing.
Why say
	$@->isa('PerlError' <mailto:$@->isa('PerlError'> ) and
$@->CriticalError <mailto:$@->critical_error> 
instead of
	$@->isa('CriticalError' <mailto:$@->isa('CriticalError'> )
?

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

		Larry Wall wrote:

		> I think Perl should move toward making die always throw an
exception
		> object of some sort, even if the user thinks they're only
throwing a
		> string.  I think you should be able to say $@->name or
whatever without
		> testing $@ first to see if it's a ref (unless you're
trying to be
		> backward compatible).

		Yes. As noted elsewhere, that's the only reason I use
C<$SIG{__DIE__}>.

		> So to partially answer your question, I don't want people
inventing new
		> syntax merely because die/eval was historically only used
to throw
		> string exceptions.

		Agreed. Code of the C<{try {} except {}> persuasion is
really just
		syntactic sugar; it's neater and more readable than using
ordinary
		conditionals after an C<eval>, but it's not exactly
essential. One for
		Perl6 perhaps.

		> More important to me, however, is the notion of
classifying all the
		> current internal exceptions so that we can trap them by
name or by
		> type without relying on the English prose.  I think this
is important
		> not so much for OO reasons, but for i18n reasons.  Given
that we're
		> extending internal exceptions to do this, I don't see any
reason why
		> the same capability shouldn't be provided for user-thrown
exceptions.

		I like this - locale-specific error text with standard error
names and
		categories would be an excellent idea. Larry, what's your
take on
		exception categories? The alternatives seem to be using an
exception
		property or the subclass name... I started by favouring the
former,
		moved to the latter after discussion here, but if Perl
itself is likely
		to define categories for standard errors, perhaps a property
would be
		less hassle after all.

		> What I *don't* want is for every program to have to pull
in a 17,000 line
		> StandardExceptions module.  This has to be lightweight on
the front end.

		Well, quite. Raising exceptions isn't an issue - the object
can be
		created on the fly in context. For querying standard
exceptions (say
		grabbing a locale-specific error text from an error code),
there may be
		no alternative to your 17,000 line module.

		OTOH, if this were done properly, there would be a lookup
table used at
		runtime for all internal errors... It could be built-in at
compile time
		if a fixed locale for a given Perl installation is
acceptable, otherwise
		we're talking about some sort of error database. Aaargh. I
suppose
		configure could allow the selection of one or more locales
all of which
		would be built into Perl... Dunno.

		Pete
		-- 
		use Disclaimer::Standard;
		my $phone='+44 1793 564450';    # "THIS IS THE COMPATIBILITY
		my $fax='+44 1793 566918';      #  POLICE. RESTORE YOUR
ORIGINAL
		my $mobile='+44 7973 725120';   #  TOKE.C AND BACK AWAY
SLOWLY."

---

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

---