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

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


References to:
Larry Wall <larry@wall.org>

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