Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news01.sunet.se!sunic!newsfeed.ACO.net!Austria.EU.net!EU.net!newsfeed.internetmci.com!news.sprintlink.net!new-news.sprintlink.net!news.interserv.net!news1.interserv.net!news From: Jerry Houston 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, 26 Mar 1996 10:19:52 -0800 Organization: Wall Data - Salsa Products Division Lines: 14 Message-ID: <31583548.4BEF@Salsa.WallData.com> References: <1996Mar14.155641.4299@schbbs.mot.com> <4irn11$7ln@mimas.brunel.ac.uk> NNTP-Posting-Host: 89184.walldata.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0GoldB1 (Win95; I) Xref: news.daimi.aau.dk comp.object:53250 comp.lang.eiffel:22523 comp.lang.c++:175189 comp.lang.beta:10682 comp.lang.java:28779 comp.lang.sather:12361 Matthew Travis wrote: [snip] > handler is the place to do cleanup and ensure a graceful exit. If the > exception is something that is recoverable, such as a user entering 5/0 in a > calculator program, then you should take care of that before an exception > is thrown. Exceptions should only be thrown for unhandle-able conditions... That's great in theory, but many of us regularly use class libraries written by others, for which we cannot or prefer not to modifiy the sources. Code in a catch{} block that recognizes that the user has fixed what was wrong, and which subsequently attempts the try{} block another time can be very useful, straightforward, and easy to read.