Re: Exception handling [Was: Re: Things to remove]
"BSOD" => huh? Oh, Blue Screen of Death. Certainly if the OS doesn't support trapping an error, then the language running on it cannot either. But if the OS does, then the language could. If the language could, then the question remains whether it should, and that's a -language topic that hasn't been discussed much. "David L. Nicol" wrote: > i think he meant the windoes95 BSOD kind of GPF; that's how I read it at leas > > Glenn Linderman wrote: > > > > Dan Sugalski wrote: > > > > > At 02:48 AM 8/24/00 +0200, Markus Peter wrote: > > > > > > >--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote: > > > > > > > >>Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal > > > >>errors, people that want to write fatal errors can switch to using "warn > > > >>...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue > > > >>firmly planted on cheek.] > > > > > > > >I can only hope this is pure irony... > > > > Indeed it was. > > > > > >There is no such thing as an ultimately fatal error - it should always be > > > >up to the user of a module wether the program should die, but I guess you > > > >see that the same and will answer me with "use eval" then ;-) > > > > > > I hope you're speaking from a perl level--a segfault pretty much spells > > > "Game Over"... > > > > I have seen and worked on C++ code implementing a database system where database > > data was read into pages marked read-only, and then code was run. When attempts > > were made to write to the data, a segment fault was generated, the fault handler > > attempted to obtain a transaction lock on the data for that page. If it was > > successful, it marked the page writable and resumed from the fault. If it was > > unsuccessful in obtaining the lock, it marked the transaction "must be aborted", > > and threw a C++ exception out of the signal handler invoked by the segfault. > > > > Just to point out that fatal is, indeed, as several people keep saying, truly in > > the eye of the catcher. > > > > That said, none of the currently proposed mechanisms permit "resume from fault" > > semantics, much less "resume from hardware fault" semantics. Sounds like good > > RFC fodder to me! > > > > One point of view might hold that "resume from hardware fault" would need only > > be implemented by a "fatal error handling" mechanism, and would not be necessary > > in a "non-fatal error handling" mechanism. > > > > -- > > Glenn > > = > > There are two kinds of people, those > > who finish what they start, and so > > on... -- Robert Byrne > > > > NetZero Free Internet Access and Email_ > > Download Now http://www.netzero.net/download/index.html > > Request a CDROM 1-800-333-3633 > > ___ > > -- > David Nicol 816.235.1187 [EMAIL PROTECTED] >My argument is the result of selectively breeding straw men -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: Exception handling [Was: Re: Things to remove]
Tony Olekshy wrote: > Glenn Linderman wrote: > > > > Just to point out that fatal is, indeed, as several people keep > > saying, truly in the eye of the catcher. > > > > That said, none of the currently proposed mechanisms permit > > "resume from fault" semantics, much less "resume from hardware > > fault" semantics. Sounds like good RFC fodder to me! > > Hi, it's me again. Not to be a pain, but RFC 88 does say: Hey, no pain. You know your RFC better than I do. Good thing, too. > retry > > There has been some discussion on perl6-language-error about the > concept of re-entering try blocks on catch, and the possibility > of using such a mechanism to replace AUTOLOAD. > > The author is of the opinion that in order to do this sort of > thing properly one should use continuations, which are being > discussed elsewhere to this RFC. > > The intent of this RFC is to provide a simple yet robust > exception handling mechanism that is suitable for error > handling, not for replacing AUTOLOAD. I do recall seeing this quote; however, replacing AUTOLOAD is a very specific instance of resuming from or retrying a fault condition. And even though a retry mechanism could be generalized from AUTOLOAD to handling other conditions, it was not at all clear that RFC 88 actually is proposing a feature called retry, that would do any sort of resume. If that was your intention, you need to add lots of beef to the "retry" method of the "Exception" class, or somewhere, to describe how to use it. When I read this quote, I thought it was just general discussion, and that that the remark about implementing retry "should use continuations" implied that this RFC was not (presently) including such a mechanism as part of it. > s/retry/resume/g I agree that in this context they are synonyms. > I'll try to make that more clear in 88v3d1. Right... is it part of the proposal, if so how does it work, what is the syntax for retrying, etc. > Yours, &c, Tony Olekshy -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: Exception handling [Was: Re: Things to remove]
Glenn Linderman wrote: > > Just to point out that fatal is, indeed, as several people keep > saying, truly in the eye of the catcher. > > That said, none of the currently proposed mechanisms permit > "resume from fault" semantics, much less "resume from hardware > fault" semantics. Sounds like good RFC fodder to me! Hi, it's me again. Not to be a pain, but RFC 88 does say: retry There has been some discussion on perl6-language-error about the concept of re-entering try blocks on catch, and the possibility of using such a mechanism to replace AUTOLOAD. The author is of the opinion that in order to do this sort of thing properly one should use continuations, which are being discussed elsewhere to this RFC. The intent of this RFC is to provide a simple yet robust exception handling mechanism that is suitable for error handling, not for replacing AUTOLOAD. s/retry/resume/g I'll try to make that more clear in 88v3d1. Yours, &c, Tony Olekshy
Re: Exception handling [Was: Re: Things to remove]
Dan Sugalski wrote: > At 02:48 AM 8/24/00 +0200, Markus Peter wrote: > > >--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote: > > > >>Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal > >>errors, people that want to write fatal errors can switch to using "warn > >>...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue > >>firmly planted on cheek.] > > > >I can only hope this is pure irony... Indeed it was. > >There is no such thing as an ultimately fatal error - it should always be > >up to the user of a module wether the program should die, but I guess you > >see that the same and will answer me with "use eval" then ;-) > > I hope you're speaking from a perl level--a segfault pretty much spells > "Game Over"... I have seen and worked on C++ code implementing a database system where database data was read into pages marked read-only, and then code was run. When attempts were made to write to the data, a segment fault was generated, the fault handler attempted to obtain a transaction lock on the data for that page. If it was successful, it marked the page writable and resumed from the fault. If it was unsuccessful in obtaining the lock, it marked the transaction "must be aborted", and threw a C++ exception out of the signal handler invoked by the segfault. Just to point out that fatal is, indeed, as several people keep saying, truly in the eye of the catcher. That said, none of the currently proposed mechanisms permit "resume from fault" semantics, much less "resume from hardware fault" semantics. Sounds like good RFC fodder to me! One point of view might hold that "resume from hardware fault" would need only be implemented by a "fatal error handling" mechanism, and would not be necessary in a "non-fatal error handling" mechanism. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: Exception handling [Was: Re: Things to remove]
Dan Sugalski wrote:
>
> Markus Peter wrote:
>
> > There is no such thing as an ultimately fatal error - it should
> > always be up to the user of a module wether the program should
> > die, but I guess you see that the same and will answer me with
> > "use eval" then ;-)
>
> I hope you're speaking from a perl level--a segfault pretty much
> spells "Game Over"...
Dan, FYI ~
Yes, from a Perl level.
In general, discussion on -errors have assumed that there will
be a class of what we are generically referring to as exceptions
that will indeed not behave according to the rules for all other
exceptions (such as being able to be caught by eval { ... } ).
Certainly segfault and hcffault (that's halt-and-catch-fire fault)
would we in that class of exceptions.
Other exceptions, such as out-of-memory, might almost be in that
class, except when the emergency out-of-memory memory pool comes
into play. I haven't though that one through.
Then there's exceptions like divide-by-zero and (if C is
in scope) cant-open-file. Clearly, these are catchable. There is
currently a running dialogue on whether or not divide-by-zero and
other such so-called "fatal" errors should be handled by a separate
mechanism from that used for so-called "non-fatal" errors like
cant-open-file, where is where you stepped in. Said dialogue will
play itself out.
Yours, &c, Tony Olekshy
Re: Exception handling [Was: Re: Things to remove]
At 02:48 AM 8/24/00 +0200, Markus Peter wrote: >--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote: > >>Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal >>errors, people that want to write fatal errors can switch to using "warn >>...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue >>firmly planted on cheek.] > >I can only hope this is pure irony... > >There is no such thing as an ultimately fatal error - it should always be >up to the user of a module wether the program should die, but I guess you >see that the same and will answer me with "use eval" then ;-) I hope you're speaking from a perl level--a segfault pretty much spells "Game Over"... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Exception handling [Was: Re: Things to remove]
--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote:
> Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
> errors, people that want to write fatal errors can switch to using "warn
> ...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue
> firmly planted on cheek.]
I can only hope this is pure irony...
There is no such thing as an ultimately fatal error - it should always be
up to the user of a module wether the program should die, but I guess you
see that the same and will answer me with "use eval" then ;-)
and from another mail:
> While nothing in RFC 88 precludes die and throw from sharing the same
> underlying code, or similarly catch/eval, doing so isn't a good idea: it
> forces people that want to use exceptions for non-fatal error handling to
> suddenly have to also handle fatal errors as well.
In which way are they forced? You simply need not catch the fatal
exceptions.
try {
...
}
catch ! $@->fatal => { ... }
That might be a bit longer to type than eval { }; do_stuff_with($@) but I
think consistency in handling is more important here.
and another mail:
> Once a (more appropriate than die) non-fatal throw/catch mechanism exists,
> the use of die for non-fatal exceptions would hopefully wither away over
> time... and if not, appropriate wrappers could be written.
I don't see why I should want that - sure, that's a way to cope with a
distinction between die and throw but without the distinction we simply do
not have the problem. And I definitely do NOT want to have a dozen wrapper
modules or whatever till that usage withered away in CPAN in 95% of the
modules after 1 year.
--
Markus Peter - SPiN GmbH
[EMAIL PROTECTED]
Exception handling [Was: Re: Things to remove]
Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal errors, people that want to write fatal errors can switch to using "warn ...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue firmly planted on cheek.] Bart Lateur wrote: > On Wed, 23 Aug 2000 17:24:23 -0600 (MDT), Nathan Torkington wrote: > > >Compile the main() program code into a subroutine called 0, and you're > >off! > > > > &0 anyone? :-) > > > >(that's digit 0, by analogy to $0) > > What would be nice about this, is that then you could use "return" in a > script to stop execution. I don't like "exit", because you can't trap > it, if ever you wrap the code in another script. > > open OUT, ">do.pl"; > print OUT "exit\n"; > close OUT; > print "before\n"; > do "do.pl"; > print "after\n"; > > Or, "die" should have a way of stopping the program without a warning > message. > > -- > Bart. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
