At 02:37 PM 8/23/00 -0700, Glenn Linderman wrote: > > This means that die can be trapped by catch, and > > that throw can be trapped by eval. > >Blecch. Orthogonality of the mechanisms is easier to understand than funny >rules, special cases, and syntactical magic. But that *is* being orthogonal. That's how Error.pm implemented it and it makes perfect sense. Nothing in RFC 88 precludes die and throw from sharing the same underlying code, or simlarly catch/eval. I think it should make it clear that they *are* the same thing. -- Peter Scott Pacific Systems Design Technologies
- Re: On the case for exception-based ... Bennett Todd
- Re: On the case for exception-based ... Peter Scott
- Re: On the case for exception-based ... Bennett Todd
- Re: On the case for exception-based ... Peter Scott
- Re: On the case for exception-based error handling. Chaim Frenkel
- Re: On the case for exception-based error handlin... Tony Olekshy
- Re: On the case for exception-based error han... Tony Olekshy
- Re: On the case for exception-based error han... Chaim Frenkel
- Re: On the case for exception-based error... Peter Scott
- Re: On the case for exception-based ... Glenn Linderman
- Re: On the case for exception-based ... Peter Scott
- Re: On the case for exception-based ... Glenn Linderman
- Re: On the case for exception-based ... Peter Scott
- Re: On the case for exception-based error... Glenn Linderman
- Re: On the case for exception-based ... Peter Scott
- Re: On the case for exception-based ... Chaim Frenkel
- Re: On the case for exception-based error handling. Glenn Linderman
- Re: On the case for exception-based error handling. Markus Peter
- Re: On the case for exception-based error handlin... Glenn Linderman
- Re: On the case for exception-based error han... Markus Peter
- Re: On the case for exception-based error... Peter Scott