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