Path: news.cs.au.dk!not-for-mail From: "Jørgen Lindskov Knudsen" Newsgroups: comp.lang.beta Subject: Re: Static vs. dynamic exceptions Date: Wed, 21 Jun 2000 11:10:11 +0200 Organization: University of Aarhus, Department of Computer Science (DAIMI) Lines: 47 Message-ID: <8iq0pm$apu7$1@xinwen.cs.au.dk> References: <20000619173848.8485.qmail@noatun.mjolner.dk> <8im02p$8s5j$1@xinwen.cs.au.dk> <8infta$9jn7$1@xinwen.cs.au.dk> <394F9765.21D28D31@skynet.be> <8ionb2$a77g$1@xinwen.cs.au.dk> NNTP-Posting-Host: nott.mjolner.dk X-Trace: xinwen.cs.au.dk 961578614 354247 255.255.255.255 (21 Jun 2000 09:10:14 GMT) X-Complaints-To: news@cs.au.dk NNTP-Posting-Date: 21 Jun 2000 09:10:14 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Xref: news.cs.au.dk comp.lang.beta:12477 Peter von der Ahé wrote in message news:yc0d7lbsxw0.fsf@ufleku.cs.au.dk... > ... > I come to wonder about constructs that are predictable from the source > code, going back to my favorite example, getInt. Consider this > program fragment: > > ... > getInt -> i; > ... > > Here, both with static or dynamic exceptions, it isn't immediate from > the source code that a runtime error (uncaught exception) can happen. > In Java I think this has been solved by requiring that all uncaught > exceptions are listed in the function prototype. Are there any plans > for addressing this in BETA? Well, the Java model is actually _not_ as you describe it. All Java exceptions who interit from the Throwable class follow the rule above. However, all other exceptions (e.g. numerical exceptions) does _not_ follow this rule - i.e. that are _not_ declares in the interface, and can be thrown through any number of message invocations. Actually, this design destinction originates from the old CLU language, and it's my interpretation, that the design rationale for this in both languages can be interpreted as originating from the exception handling versus fault tolerance discussion in one of my previous postings. Now, in this setting you can justify a relationship between the Throwable exceptions in Java with static exception handling in BETA, and the other exceptions in Java with our discussions on introducing some form of dynamic exception handlinh in BETA. However, the Java model makes the distinction between an error and a fault based on the _type_ of the exception. I really do not believe in that model (making it impossible to automatically convert an error situation into a fault). In the BETA proposal, the distinction is a matter of the specific exception occurrence, and static exceptions, that is not handled, is automatically converted into 'faults' (i.e. converted into dynamic exceptions). Regards, Jørgen