From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3EB87BDC.30305@null.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit References: <3EB37781.1030903@null.net>, <1092ecb1fccdb5af51c89a1854558c4f@vitanuova.com> Subject: Re: [9fans] same functions everywhere Date: Wed, 7 May 2003 08:43:56 +0000 Topicbox-Message-UUID: a11f1632-eacb-11e9-9e20-41e7f4b1d025 rog@vitanuova.com wrote: > what kinds of exceptional conditions are you thinking about here? What would be considered "problems in completing the assignment". Typically, running out of some system resource, or a already created data structure is found to have an "impossible" value in some field, etc. The idea is that things that are expected to occur quite a lot should be dealt with in the main logic, since not taking them into account would be an essential lack of function, but that things that should rarely occur and are not of the same kind as expected results should be treated as exceptions. Looking at it another way, if it seems that a situation should be handled within an ongoing loop then it's not a candidate for an exception, but if it seems that the loop needs to be aborted because it would be pointless to continue in the same vein, then it should be an exception. Yet another take on the same thing: If local tactics are expected then it's not a candidate for an exception, but if a global strategy for recovery from the condition is expected, then it's an exception. In practice, the distinction is usually clear. One could debate whether getc() returning EOF with ferror() returning false should be handled as an exception rather than as an exceptional value for the data, but I'm inclined to think that it should, after consideration of the problems that having in-band signals has caused.