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

[Olaf Wagner]

Quoting Mika Nystrom <mika at async.caltech.edu>:

>
> It's as simple as that!?

IMO it should just work. See m3-sys/m3tests/src/p2/p208/Main.m3:
% cat m3-sys/m3tests/src/p2/p208/Main.m3
MODULE Main;

IMPORT RuntimeError, IO, Process;

CONST Tag = RuntimeError.Tag;

PROCEDURE CatchAssert() =
   BEGIN
     TRY
       <*ASSERT FALSE*>
     EXCEPT
       RuntimeError.E( t ) =>
       IO.Put( "OK: caught RuntimeError.Assert: " & Tag( t ) & "\n" );
     END;
   END CatchAssert;

PROCEDURE TestAll() =
   BEGIN
     CatchAssert();
   END TestAll;

BEGIN
   TRY <*NOWARN*>
     TestAll();
   EXCEPT
   ELSE
     IO.Put( "ERROR: caught unexpected exception\n" );
     Process.Exit( 1 );
   END;
END Main.

Olaf

>
> Wow!
>
> Tony Hosking writes:
>> 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__=--
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194