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

Re: A common base exception object for Perl - RFC



Pete Jordan writes:
: Graham Barr wrote:
: 
: > I feel that there needs to be some defined "syntactic sugar" otherwise
: > having a defined class is of no great benefit as people will use it
: > differently.
: 
: TMTOWTDI :)
: 
: One for Larry, I think: should Perl prescribe, suggest or be agnostic
: about exception handling syntax?

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

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.

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.

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.

Larry


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

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