Glenn Linderman wrote:
>
> More seriously, I agree there is no need for a "try" keyword... it just
> starts a block, which could just as well be any other block.
This makes especially good sense if the catch{} is INSIDE the relevant
block, rather than following it.
Because without "try" (or its equivalent), there would be ambiguity
as to what block the second catch below is applying to:
qc/try/ {
might_throw_E1_or_E2();
}
catch E1 {
might_throw_E2();
}
catch E2 {
# where did this E2 come from?
}
But no such ambiguity exists here:
qc/try/ {
might_throw_E1_or_E2();
catch E1 {
might_throw_E2();
}
catch E2 {
# we know exactly where this E2 came from!
}
}
--
John Porter
Aus tiefem Traum bin ich erwacht.
- Re: English language basis for &qu... John Porter
- Re: English language basis for &qu... Nathan Torkington
- Re: English language basis for &qu... Peter Scott
- Re: English language basis for &qu... John Porter
- Re: English language basis for &qu... Stephen P. Potter
- Re: English language basis for &qu... Tony Olekshy
- Re: English language basis for &qu... John Porter
- Re: English language basis for &qu... John Porter
- Re: English language basis for &qu... Peter Scott
- Re: English language basis for &qu... Glenn Linderman
- Re: English language basis for &qu... John Porter
- Re: English language basis for &qu... skud
- Re: English language basis for &qu... Piers Cawley
- Re: English language basis for &qu... David L. Nicol
- Re: RFC 78 (v1) Improved Module Ve... Chaim Frenkel
- Re: RFC 78 (v1) Improved Module Ve... Graham Barr
- Re: RFC 78 (v1) Improved Module Ve... Bennett Todd
- RFC 78 and shared vs unshared modu... Steve Simmons
- Re: RFC 78 and shared vs unshared ... Bennett Todd
- Re: RFC 78 (v1) Improved Module Versioning And Searching Steve Simmons
