Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!news99.sunet.se!nntp-trd.UNINETT.no!nntp.uio.no!news.cais.net!news.cais.com!news From: Eric Vought 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 Date: Tue, 09 Apr 1996 17:31:49 -0400 Organization: Capital Area Internet Service info@cais.com 703-448-4470 Lines: 40 Message-ID: <316AD745.68DE37AD@ids2.idsonline.com> References: <31647113.13BD8C66@cygnus.com> <4ke1kp$pem@newsbf02.news.aol.com> NNTP-Posting-Host: ip226.idsonline.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (X11; I; Linux 1.2.13 i586) Xref: news.daimi.aau.dk comp.object:53948 comp.lang.eiffel:22717 comp.lang.c++:177677 comp.lang.beta:10716 comp.lang.java:32660 comp.lang.sather:12431 > Real world case in point. Imagine a fictious object runtime which must > have one binary support the range of operating systems with the interface > identified as Win32. Under Win32s many file operations will return an > error code 87 when in fact Windows95 or Window NT will give a notification > code with more meaning. on the Win32s platform an error code 87 may > indicate a dire consequence or merely be an informative notification. > Structuring the File System framework to use exception handlers can allow > an 87 error code to raise an exception and let the arbitrator determine > the settlement of the outcome. That is to say, is this a trivial > notification? Or, is this a serious error condition. In the first case, we > may resume. In the second, we must take direct alternative action. This is a perfect example of what I see as a bad use of exceptions. When the filesystem code recieves an error code 87, it should *not* throw an exception. Instead, it should try to determine the nature of the error *within* the method and then throw a more appropriate exception in a serious case. The problem is that throwing and processing an error in order to determine that, in fact, the situation is not dire takes just as long as processing a real error. Since, presumably, non-dire errors occur more often than dire errors, you are wasting a significant amount of processing power to throw and catch these exceptions. Additionally, you are violating encapsulation by allowing the error handling routine to affect the execution path of the method. This means that the caller must *know* how to affect the method's internal state, and therefore must know implementation details of the method. BAD. The better way to do it is to have the public method call private methods which will terminate on errors (either by returning a signal value or throwing an exception). The public code then decides whether the condition is an error and either retries or resumes operation by calling further private methods or throws an exception from there. Remember that the primary reason for exceptions is to support OOP and data encapsulation. In other words, for informing a client that something has occurred and allowing them to deal with it *without* revealing internal details. Within implementation code (which seems to be what resumption most directly supports), where one knows how the condition will be handled, return values and branch statements are more efficient, often simpler, and more elegant.