"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
___________________________________________________________
