Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news01.sunet.se!sunic!mn6.swip.net!plug.news.pipex.net!pipex!tank.news.pipex.net!pipex!news.mathworks.com!fu-berlin.de!news.belwue.de!news.uni-mannheim.de!ipx2.rz.uni-mannheim.de!mw From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather Subject: Re: What Should An Exception Handling Do? -- Clarification of rules Followup-To: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather Date: 26 Mar 1996 15:59:09 GMT Organization: --- Lines: 50 Message-ID: <4j948d$t3d@trumpet.uni-mannheim.de> References: <1996Mar25.160702.14229@schbbs.mot.com> NNTP-Posting-Host: ipx2.rz.uni-mannheim.de X-Newsreader: TIN [version 1.2 PL2] Xref: news.daimi.aau.dk comp.object:53353 comp.lang.eiffel:22557 comp.lang.c++:175484 comp.lang.beta:10691 comp.lang.java:29312 comp.lang.sather:12372 David L. Shang (shang@corp.mot.com) wrote: > But an exception is not necessarily an error. Sometimes it is an > condition that requires some extraordinary computation, a condition > that is not supposed for a regular case, [...] Let's look at the problem with fresh eyes, without thinking immediately about using the technical feature called "exception" in a few programming languages. Some routine (often supposed to be reused for different contexts) wants the "advice" of its caller (or the caller's caller etc.) how to handle an unusual condition ("advice" might imply activities, like a user query). To make this "advice" general, it should be some code supplied by the caller(s). Thus we need to somehow (see below) pass a routine to the given library routine; let's call this condition-handling routine the "handler". Since the handler might have to act depending on local information in the call chain, it needs some way to access such information - which should be of no concern whatsoever to a library routine which encounters the condition. In object oriented languages, this means that a handler would in fact be the invocation of some object's method - thus any local differences of various handlers can be specified by deriving from some general handler (this may be by inheritance or delegation, depending which facilities are more appropriate for the given situation/language). In applicative languages like Lisp, Scheme or Dylan, you wouldn't even need objects with methods, but could alternatively just create a closure in the environment of the handler. (One might say that objects are the poor man's closures ;-) The remaining question is how the library routine would know which handler it should use. Depending on the situation, one might choose an additional argument, or place it into some context data structure which is available anyway, or temporarily bind a globally visible variable to the handler while it's supposed to be active (and restore the previous handler after the scope of the local handler is left). What the condition handling system of languages like Lisp and Dylan provides (in addition to the mechanism e.g. of C++) is an implicit management for the dynamic binding. If it's true that this style of handling is rare, it shouldn't be problematic to do this by yourself. If you find that you need it frequently, you can as well design some abstractions for this purpose. Given that repairing a problematic condition requires much more knowledge - and a more intimate cooperation between the signaling routine and the handler - than merely receiving a failure notification, it doesn't appear too horrible that one needs to make it somewhat more explicit. -- Marc Wachowitz