Graham Barr wrote:
> Peter Scott wrote:
> > Tony Olekshy wrote:
> > > Graham Barr wrote:
> > > >
> > > > I am of the opinion that only a class name should follow
> > > > catch. If someone wants to catch based on an expression
> > > > they should use
> > > >
> > > > catch {
> > > > if (<expr>) {
> > > > }
> > > > else {
> > > > # rethrow the error
> > > > }
> > > > }
> > >
> > > Then you will be glad to know that RFC 88, in the not quite
> > > ready version two release, allows you do to just that.
> >
> > "Allows" isn't the same as "should be the only way" though.
> >
> > Graham, did you base your opinion on usability, parseability,
> > both, neither?
>
> Probably both along with simplicity, ie keeping the language simple.
Here's what I really think we should do, in light of the fact that I
too don't want to put *anything* into the Perl core unless it *can't*
be done as a module (for some value of can't, even if certain hooks
are provided and other enhancements are made in re performance).
I think Perl's canonical exception handling mechanism should be in
a core (ie, sanctioned) module, not built-in at all. I think die,
eval, and $@ should be left *exactly* as before. I think C<use
fatal;> is a good idea, but I'm not going to lose any sleep over it.
Everything in RFC 88 can be done in Perl 5 (modulo syntax and some
sugar), and in fact is done in the Try.pm module in reference
[TRY-2000] in RFC 88. Syntax enhancements will likely be possible
with Perl 6; I can even imagine an RFC on "Clause-based subroutine
argument parsing." (which would make RFC 88 do-able as a module
without any significant syntax changes).
In fact, not only would I be pleased and honoured to author the
Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
reference implementation.
Peter, I think we should make this approach more clear in RFC 88.
Yours, &c, Tony Olekshy
