Path: news.cs.au.dk!not-for-mail From: nospam2159@cs.au.dk (Peter von der =?iso-8859-1?q?Ah=E9?=) Newsgroups: comp.lang.beta Subject: Re: Static vs. dynamic exceptions Date: 20 Jun 2000 14:47:54 +0200 Organization: Computer Science Department of the University of Aarhus Lines: 61 Message-ID: References: <20000619173848.8485.qmail@noatun.mjolner.dk> <8im02p$8s5j$1@xinwen.cs.au.dk> <8infta$9jn7$1@xinwen.cs.au.dk> NNTP-Posting-Host: ufleku.cs.au.dk Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: xinwen.cs.au.dk 961505274 320814 255.255.255.255 (20 Jun 2000 12:47:54 GMT) X-Complaints-To: news@cs.au.dk NNTP-Posting-Date: 20 Jun 2000 12:47:54 GMT X-Attribution: Ahe User-Agent: Gnus/5.0806 (Gnus v5.8.6) Emacs/20.6 Xref: news.cs.au.dk comp.lang.beta:12455 >>>>> "JLK" == Jørgen Lindskov Knudsen writes: JLK> There is no connection between leave/restart and static JLK> exception handling - these two issues have been discussed and JLK> designed separately (look e.g. at [ref1] or the chapter in the JLK> BETA book). The only connection is that I'm pretty sure that I could implement dynamic exceptions in BETA if leave/restart wasn't so limited. I'm also thinking about closures and call/cc as known from scheme. But maybe this is a bit far fetched for BETA :-) [...] JLK> Thus, 'simulation' isn't sufficient - could you on the other JLK> hand implement an abstraction with the necessary semantics, JLK> etc., we would be in another ballgame. This was just to "prove" that at least dynamic exceptions is a superset of static exceptions (maybe not a proper superset). But let me try harder. I might even come up with something that you could use in BETA :-) If static exceptions is a subset of dynamic exceptions it should be possible to extend static to dynamic: Lets say that we have the well known exception pattern and a try pattern. Normally when an uncaught/unbound static exception occurs we end up with a runtime error. (In my experience most of the errors in the Mjolner tools are unbound exceptions.) One way to add dynamic exceptions to BETA could be to let try patterns catch unbound exceptions, that is: try (# catch::(# (* handle second exception *) #) do getInt(# syntaxError::(# (* handle first exception *) #) #); getInt (* a second exception can occur here *) #) To fully implement this the exception pattern should be aware of the nesting level of try blocks and be able to call the catch methods in all the try blocks on the stack until one handles the exception. JLK> However, whether static and dynamic ex.handling is a choice JLK> between models, or both are needed is an open question right now JLK> - actually this very subject was discussed at the Workshop on JLK> Exception Handling at the ECOOP'2002 conference last week. JLK> Currently, my conception is that both mechanisms have their JLK> merit (for slightly different purposes), perhaps warrenting JLK> having both (actually a very preliminary design exists for JLK> BETA). I'm looking forward to this. Would it be possible to see this preliminary design? -- YMMV