Peter Scott wrote:
>
> At 11:04 PM 8/18/00 -0600, Tony Olekshy wrote:
> >
> > As currently promulgated, catch "Foo" {} will always catch,
> > because "Foo" is true. Will this cause confusion for developers
> > who meant to say catch Foo {}?
>
> This is a good point, but I'm not about to concede an extra
> keyword :-)
Nor do I.
> 3. The case you point out - constant string used instead of
> classname - is by far the most likely occurrence of the
> mistake. So just have the parser look for it and issue a
> compilation warning.
I added this one.
> >And while I'm on the topic, how likely is it that
> >
> > catch <expr> { ... }
> >
> >is going to be parsable? Does Perl 5 do that in any cases?
>
> Well, look at map. Perl can parse
>
> map <expr>, <list>
>
> We're asking it to find a left brace instead of a comma.
> Where might this break down? Here's one possibility:
>
> my ($hash,%hash);
> ...
> catch $hash { ... }
>
> Okay, suppose we change the syntax to
>
> catch <expr>, <block>
>
> We know that's doable because map can do it. Suppose we just
> require that comma in all cases except the catch-all. Then we
> can write:
>
> catch Exception::IO => { ... }
>
> catch Exception::IO, Exception::SQL => { ... }
>
> (This one should be doable because the parser can tell that it
> hasn't found a block after that first comma, so it knows to
> keep going)
>
> catch $@->isa('Exception::Arithmetic') => { ... }
>
> catch { ... }
>
> Now the question is whether perl can tell that block isn't
> some expression like an anonymous hash constructor. I'm no
> expert - my guess is that it could tell by the time it
> discovered no comma following the block.
Sounds good. Catch now requires a "," or => before its block
unless that would be the only token between C<catch> and the
block.
Yours, &c, Tony Olekshy
