[M3devel] an old, recurring issue: mapping runtime errors to exceptions?
Mika Nystrom
mika at async.caltech.edu
Wed Apr 22 04:38:18 CEST 2009
It's as simple as that!?
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. =
>>> ; 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. =
>>> ; 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