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

[Randy Coleburn]

Mika:
 
You state that "Checked runtime errors cannot violate invariants of the runtime system, so it ought to be safe to ..."
 
Are you sure this statement is true for all implementations?
 
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.
 
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.
 
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?
 
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 
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.  

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 = 0x80c69c8 = LockMutex + 0x28 in /usr/ports/lang/ezm3/work/ezm3-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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090421/a4bf2ed5/attachment-0002.html>