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

[Tony Hosking]

CM3 does map some (I'm not sure if all) run-time errors to  
exceptions.  See RuntimeError.i3 for details of what exceptions might  
occur.

On 22 Apr 2009, at 08:41, Mika Nystrom wrote:

>
> 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__=--