[M3devel] an old, recurring issue: mapping runtime errors to exceptions?

Mika Nystrom mika at async.caltech.edu
Wed Apr 22 00:41:19 CEST 2009


Well the point of "safety" is that the system can guarantee that the
runtime environment hasn't been damaged by a misbehaving program, no?

In fact, in Threads 3 there are not one but *two* reports of
implementations that "reflect" runtime errors as exceptions.  On
of them is SPIN, the other is the commercial CM3 with JVM.

See

http://www.modula3.org/threads/3/

Nelson's article in Threads 2 doesn't give the possibility of having
had the runtime invariants violated as a reason to abort.  His
arguments are more practical, having to do with debugging.  I agree,
and I think that the default method of dealing with runtime errors
should be to abort the program.  But it just is very unfriendly in
an interactive environment, and I would love some kind of (possibly
very implementation-dependent) way of catching the runtime error.
The way Java does it would be ideal, I think.....

Nelson's article is here

http://www.modula3.org/threads/2/

[Tony, the link in your M3 bibliography is broken!]

I'm running this example in a PM3/EZM3 environment right now but
that's not relevant.  The code I showed you *should* crash.  In
plain M3 it was:

    TextWr.ToText(NIL) 

But in an interactive environment, the user can do this sort of
thing.  It should give you a nasty error message, not crash your
whole environment.  

     Mika



"Randy Coleburn" writes:
>This is a MIME message. If you are reading this text, you may want to 
>consider changing to a mail reader or gateway that understands how to 
>properly handle MIME multipart messages.
>
>--=__PartBC941634.0__=
>Content-Type: text/plain; charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>
>Mika:
>=20
>You state that "Checked runtime errors cannot violate invariants of the =
>runtime system, so it ought to be safe to ..."
>=20
>Are you sure this statement is true for all implementations?
>=20
>I would tend to think that SPIN was able to do this mapping for itself, =
>but in general, it would be difficult to be able to do this for any =
>arbitrary OS environment, esp with differences in underlying libraries and =
>implementations, which is part of what Greg alluded to in the Threads =
>article you reference.
>=20
>Note also on pg 47 of the green book under "2.5.7 Safety" the notes about =
>intrinsic safety and when the compiler makes the guarantee vs. the =
>programmer.
>=20
>I also note from the path in your example (ezm3) that you may not be using =
>the current cm3.  Is it possible that the NIL dereference problem in your =
>example has been solved in a later implementation?
>=20
>Regards,
>Randy
>
>>>> Mika Nystrom <mika at async.caltech.edu> 4/21/2009 5:41 PM >>>
>
>Hello Modula-3ers,
>
>I know this is a question that comes up from time to time, and I
>am aware of Greg Nelson's short article in "Threads" about why=20
>Modula-3 doesn't map runtime errors to exceptions, but the Green Book
>does allude to mapping runtime errors to exceptions, and I know that
>the SPIN OS did that.
>
>How hard would this be to support in CM3?
>
>Attached is a transcript of an interactive session with my current
>Scheme environment.  I think it ought to be obvious why I ask about
>exceptions.  In Modula-3, from safe code, only checked runtime errors
>can occur.  Checked runtime errors cannot violate invariants of the
>runtime system, so it ought to be safe to convert them to exceptions
>that can be caught, and then permit the program to continue. =20
>
>I realize this isn't *always* what you want to do, but in an interactive
>environment, making the system dump core on runtime errors sort of
>spoils the whole experience.
>
>In this application, there are many places where you may want to
>raise an exception that hasn't been declared.  In a non-interactive
>environment, it is probably best to go for the core dump, but in
>an interactive environment, it seems to me it ought to just return
>control to the read-eval-print loop....

>     Mika
>
>LITHP ITH LITHENING.
>> (define wr (scheme-procedure-stubs-call '(TextWr . New) '()))
>wr
>> wr
><Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M>
>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '())
>#t
>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '())
>"hello!"
>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '())
>""
>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '())
>#t
>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '())
>#t
>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '())
>#t
>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '())
>#t
>> (scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '())
>#t
>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '())
>"hello!hello!hello!hello!hello!"
>> (scheme-procedure-stubs-call '(TextWr . ToText) (list '()) '())
>
>
>***
>*** runtime error:
>***    Segmentation violation - possible attempt to dereference NIL
>***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 in /usr/ports/lang/ezm3/work/e=
>zm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix.m3
>***
>
>  use option @M3stackdump to get a stack trace
>Abort
>
>
>
>
>
>
>
>CONFIDENTIALITY NOTICE:  This email and any attachments are intended =
>solely for the use of the named recipient(s). This e-mail may contain =
>confidential and/or proprietary information of Scientific Research =
>Corporation.  If you are not a named recipient, you are prohibited from =
>making any use of the information in the email and attachments.  If you =
>believe you have received this email in error, please notify the sender =
>immediately and permanently delete the email, any attachments, and all =
>copies thereof from any drives or storage media and destroy any printouts =
>of the email or attachments.
>
>EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain =
>technical data subject to U.S export restrictions under the International =
>Traffic in Arms Regulations (ITAR) or the Export Administration Regulations=
> (EAR).  Export or transfer of this technical data and/or related =
>information to any foreign person(s) or entity(ies), either within the =
>U.S. or outside of the U.S., may require export authorization by the =
>appropriate U.S. Government agency prior to export or transfer.  In =
>addition, technical data may not be exported or transferred to certain =
>countries or specified designated nationals identified by U.S. embargo =
>controls without prior export authorization.  By accepting this email and =
>any attachments, all recipients confirm that they understand and will =
>comply with all applicable ITAR, EAR and embargo compliance requirements.
>
>
>--=__PartBC941634.0__=
>Content-Type: text/html; charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>Content-Description: HTML
>
><HTML><HEAD>
><META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15=
>">
><META content=3D"MSHTML 6.00.6000.16825" name=3DGENERATOR></HEAD>
><BODY style=3D"MARGIN: 4px 4px 1px">
><DIV>Mika:</DIV>
><DIV> </DIV>
><DIV>You state that "Checked runtime errors cannot violate invariants of =
>the runtime system, so it ought to be safe to ..."</DIV>
><DIV> </DIV>
><DIV>Are you sure this statement is true for all implementations?</DIV=
>>
><DIV> </DIV>
><DIV>I would tend to think that SPIN was able to do this mapping for =
>itself, but in general, it would be difficult to be able to do this for =
>any arbitrary OS environment, esp with differences in underlying libraries =
>and implementations, which is part of what Greg alluded to in the Threads =
>article you reference.</DIV>
><DIV> </DIV>
><DIV>Note also on pg 47 of the green book under "2.5.7 Safety" the notes =
>about intrinsic safety and when the compiler makes the guarantee vs. the =
>programmer.</DIV>
><DIV> </DIV>
><DIV>I also note from the path in your example (ezm3) that you may not be =
>using the current cm3.  Is it possible that the NIL dereference =
>problem in your example has been solved in a later implementation?</DIV>
><DIV> </DIV>
><DIV>Regards,</DIV>
><DIV>Randy<BR><BR>>>> Mika Nystrom <mika at async.caltech.edu> =
>4/21/2009 5:41 PM >>><BR><BR>Hello Modula-3ers,<BR><BR>I know =
>this is a question that comes up from time to time, and I<BR>am aware of =
>Greg Nelson's short article in "Threads" about why <BR>Modula-3 doesn't =
>map runtime errors to exceptions, but the Green Book<BR>does allude to =
>mapping runtime errors to exceptions, and I know that<BR>the SPIN OS did =
>that.<BR><BR>How hard would this be to support in CM3?<BR><BR>Attached is =
>a transcript of an interactive session with my current<BR>Scheme environmen=
>t.  I think it ought to be obvious why I ask about<BR>exceptions.&nbsp=
>; In Modula-3, from safe code, only checked runtime errors<BR>can =
>occur.  Checked runtime errors cannot violate invariants of the<BR>run=
>time system, so it ought to be safe to convert them to exceptions<BR>that =
>can be caught, and then permit the program to continue.  <BR><BR>I =
>realize this isn't *always* what you want to do, but in an interactive<BR>e=
>nvironment, making the system dump core on runtime errors sort of<BR>spoils=
> the whole experience.<BR><BR>In this application, there are many places =
>where you may want to<BR>raise an exception that hasn't been declared.&nbsp=
>; In a non-interactive<BR>environment, it is probably best to go for the =
>core dump, but in<BR>an interactive environment, it seems to me it ought =
>to just return<BR>control to the read-eval-print loop....<BR><BR> &nbs=
>p;   Mika<BR><BR>LITHP ITH LITHENING.<BR>> (define wr =
>(scheme-procedure-stubs-call '(TextWr . New) '()))<BR>wr<BR>> wr<BR><=
>Modula-3 object : TextWr.T, BRANDED TextWr_^%#%^__0001M><BR>> =
>(scheme-procedure-stubs-call '(Wr . PutText) (list wr "hello!") '())<BR>#t<=
>BR>> (scheme-procedure-stubs-call '(TextWr . ToText) (list wr) =
>'())<BR>"hello!"<BR>> (scheme-procedure-stubs-call '(TextWr . ToText) =
>(list wr) '())<BR>""<BR>> (scheme-procedure-stubs-call '(Wr . PutText) =
>(list wr "hello!") '())<BR>#t<BR>> (scheme-procedure-stubs-call '(Wr . =
>PutText) (list wr "hello!") '())<BR>#t<BR>> (scheme-procedure-stubs-call=
> '(Wr . PutText) (list wr "hello!") '())<BR>#t<BR>> (scheme-procedure-st=
>ubs-call '(Wr . PutText) (list wr "hello!") '())<BR>#t<BR>> (scheme-proc=
>edure-stubs-call '(Wr . PutText) (list wr "hello!") '())<BR>#t<BR>> =
>(scheme-procedure-stubs-call '(TextWr . ToText) (list wr) '())<BR>"hello!he=
>llo!hello!hello!hello!"<BR>> (scheme-procedure-stubs-call '(TextWr . =
>ToText) (list '()) '())<BR><BR><BR>***<BR>*** runtime error:<BR>*** &n=
>bsp;  Segmentation violation - possible attempt to dereference =
>NIL<BR>***    pc =3D 0x80c69c8 =3D LockMutex + 0x28 in =
>/usr/ports/lang/ezm3/work/ezm3-1.0/libs/m3core/src/thread/POSIX/ThreadPosix=
>.m3<BR>***<BR><BR>  use option @M3stackdump to get a stack trace<BR>Ab=
>ort<BR><BR><BR><BR><BR><BR><BR></DIV></BODY></HTML>
>
>--=__PartBC941634.0__=--



More information about the M3devel mailing list