Re: errors and their keywords and where catch can return toandst uff like that
On Mon, Aug 14, 2000 at 10:15:21PM -0700, Peter Scott wrote:
At 08:56 PM 8/14/00 -0600, Tony Olekshy wrote:
consider this:
try { may_throw_1; }
catch { may_throw_2; }
catch { may_throw_3; }
finally { may_throw_4; }
That's either a syntax error or a no-op. More likely the latter. If you
have multiple catch blocks which could catch the same exception, only the
first one should execute.
Yes.
Graham.
Re: RFC 63 (v3) Exception handling syntax
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL RFC 80 proposes standard exception classes and methods for core exceptions.
PRL This RFC doesn't need to repeat those, but it can expound upon the
PRL semantics that exception classes ought to have. Assume wlog that they
PRL all inherit from a base class, CException. Some people think that
PRL exceptions should not be rethrown implicitly. We can provide a boolean flag
PRL in the class or even the exception object itself to be checked for this:
PRL sub Exception::IO::implicit_rethrow { 0 }# One class
PRL sub Exception::implicit_rethrow { 0 }# All classes
PRL throw Exception::Socket(implicit_rethrow = 0); # Just this exception
PRL [Note: it had been proposed that this functionality would be provided by a
PRL method Cuncaught_handler which would be called if an exception wasn't
PRL caught.
PRL But if that routine decided to rethrow the exception, the Ccontinue block
PRL would not get called at the right time.]
Please include the comments about global variables and action at a distance.
PRL =head2 Exception classes - ignoring
PRL Note that we could also make it possible to selectively or globally ignore
PRL exceptions, so that perl continues executing the line after the Cthrow
PRL statement. Just import a Cignore function that takes a class name:
PRL ignore Exception::IO; # Ignore all I/O exceptions
PRL ignore Exception; # Ignore all exceptions
PRL and when perl sees the Cthrow, it just does nothing. (Or do it by
PRL overriding a base class method as for Cimplicit_rethrow if you don't want
PRL to put another function in the namespace.) Since Cthrow and Cdie
PRL should be essentially identical, this would allow any kind of exception to
PRL be ignored, not just the ones that were Cthrown. This is not necessarily
PRL a good thing, of course.
Oh, no! Are you really suggesting that after
open (FOO, "nonesuch") or throw "file not found"
The next statement continues??
How in $DIETY's name do you expect to protect code?
PRL =head2 $SIG{__DIE__}
PRL $SIG{__DIE__} needs to be triggered only as a Ilast resort
PRL instead of firing immediately, since it messes with the mind of this and
PRL every other decent exception handling mechanism. Perhaps it should be axed
PRL altogether. Please.
$SIG{DIE} should die. Action at a distance. Global. Can't know what
other threads or modules want done here.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Unify the Exception and Error Message RFCs?
On Sun, Aug 13, 2000 at 07:35:06PM -0700, Peter Scott wrote: At 03:30 PM 8/13/00 -0500, David L. Nicol wrote: Whose RFC deals with this? 63, 70, 80, 88 and 96. There would appear to be a groundswell of interest :-) Well yes, but they represent three authors with (as best I can tell) pretty similar views of what needs done. With advance apologies for the over-simplification, these RFCs very briefly summarize to: 63 - Error handling syntax to be based on fatal.pm, a Java-ish try/catch (Peter Scott). 70 - Allow full error handling via exception-based errors based on expansion of and addition to fatal.pm (Bennett Todd) 80 - Builtins should permit try/throw/catch as per Java/fatalpm style (Peter Scott). 88 - Propopses error handling via mechanisms of try, throw, except, etc. (Tony Olekshy). 96 - Proposes establishing a base class for exception objects, which could work with either of the two groups above and might subsume RFC3 as well (Tony Olekshy) I'd like to see these throw into a post (possibly including RFC3 (Brust) as well), and pulled out a single proposal with o a unified proposal for a general try/throw/catch error handling mechanism for perl o a recommended object-based implementation of it o recommended areas where it should be applied in the perl core o a mechanism allowing programmers to take over error message production for the above group of items and a separate proposal for o a mechanism allowing programmers to take over error message production for other types I'm assuming that not all errors would move to the object or try/catch sort of arrangement; there are lots of times that return values or unrecoverable errors are all you really need. For the last, one should use `eval' if you really need to catch them; but an ability to override the error message may well be sufficient in most cases. And should the first proposal fail, the second becomes even more critical. IMHO trading six RFCs for two will greatly improve the chance of passing.
Re: Exceptions and Objects
Jonathan Scott Duff [EMAIL PROTECTED] writes: On Sun, Aug 13, 2000 at 10:51:24PM -0700, Peter Scott wrote: Could be. I'd be interested in seeing non-OOP proposals that do what I want exceptions to do, I have a hard time imagining one. Well, what is it that you want exceptions to do? What does it mean for an exception to have semantics? When an exception is thrown does something special happen whether it's caught or not? Yes. In my proposal, if it's caught, the catcher examines the exception object. If it isn't caught, the program dies with the message attribute as text. This doesn't show that the exception object itself has any semantics. If the catcher examines, the object is being passive. Does the object *do* anything? I want it to be able to. Depends on how you write it... -- Piers
