From J.Reid@letterbox.rl.ac.uk Wed Aug 3 12:13:15 1994 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA11241 (5.65c8/IDA-1.4.4j for ); Wed, 3 Aug 1994 12:13:15 +0200 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Wed, 03 Aug 94 11:12:46 BST Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Wed, 3 Aug 1994 11:10:50 +0100 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA16124; Wed, 3 Aug 94 11:12:54 BST Date: Wed, 3 Aug 94 11:12:54 BST From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9408031012.AA16124@jkr.cc.rl.ac.uk> To: Karl-Heinz.Rotthaeuser@gmd.de Subject: Re: (SC22WG5.603) Exception Handling Proposal (Ref. N974) Cc: SC22WG5@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 Here is part 2 of my reply. Please remember that the current version is pp 166-180 of N995. > > 2. Global name space for exceptions > > If the global scope of exception names should really be a > problem (We don't think it is), then we would prefer the > following (simple) solution: > > - disallow user signal names and limit the exception names > to intrinsic ones (such as ALLOCATION_ERROR), > > - add USER_SIGNAL (i.e. "unspecified signal caused only by > the SIGNAL-statement") to the set of intrinsic exceptions, > and > > - add an optional parameter ERROR_INFORMATION to the SIGNAL > statement and add some corresponding inquiry functionality for > this error information to allow the transport of some > unspecified additional error information from the signal > raising code to the signal handling code. I am, of course, pleased to hear that you do not think the global scope of exception names is a problem. What you suggest here is very near what we had in earlier versions, and your idea of ERROR_INFORMATION sounds like a worthwhile improvement. However, several people (notably Lawrie Schonfelder and Mike Delves) requested user-named conditions, regarding the single user-defined condition as too crude a mechanism. I felt pleased that we were able to provide them without compromising the aim of a simple straightforward proposal. I prefer to keep what we have. I think the global scope can be addressed by careful use of names such as hsl_ma28_singular for a singular matrix found by the Harwell Subroutine Library code MA28. Something similar would have to be done within ERROR_INFORMATION in your proposal. > > 3. Exceptions in handler blocks > > What happens if exceptions occur during the execution of a > handler block? Do they cause a branch to the beginning of the > handler block (since the handler is part of the ENABLE > construct controlled by the handler)? When do such exceptions > cause a branch? (If they do not cause any branch until the end > of the handler block: are the signals set quiet at this > point?). > We think some further specifications are needed. > The intention is that the code in a handler is no different from any other code - an exception is handled if the statement is within an enable block for the condition. The statement might be within an enable block for an enable construct nested in the original handler or the original enable construct might be nested in an outer enable block. In either case, transfer is to another handler (inner or outer). Or, if there is no such nest, the system looks for a handler higher up in the call chain. The new text for 8.1.5.1 says: The handle block is executed only if execution of the enable block leads to the signaling of one or more of the conditions. The new text for 8.1.5.3 says: A processor may signal a condition while executing a statement that is not in an enable block for the condition. If in a subprogram, a return is executed without alteration of the values of the conditions. If in a main program, a stop is executed and the processor must issue a warning on the default output unit. So I think the present text is OK. Would it help to change 'signaling' in the first footnote after R835f to 'signaling in the enable block'? > > 4. Intrinsic error conditions > > 4.1) New SYSTEM_ERROR condition: > We think it's too restrictive to say that only the > intrinsic exceptions (such as ALLOCATION_ERROR ...) may be > raised by the processor (i.e. without explicit SIGNAL > statements). > Instead, some new intrinsic exception type, e.g. > SYSTEM_ERROR, should be defined which may be raised any > time under conditions which are processor-defined (this > could allow to write portable code to handle such > processor-dependent conditions by e.g. properly closing a > large complex application). Sounds reasonable to me, though no-one else has requested this. I will prepare text and we can try a straw vote in Edinburgh. > > 4.2) ALLOCATION_ERROR/INSUFFICIENT_STORAGE: > We don't think that it is useful to distinguish between > these two kinds of exceptions. The difference is that allocation is more under the control of the programmer. Let's try a straw vote on this. I think what we have is OK, but would not object strongly to merging them. > > 4.3) UNDEFINED: > This condition should be dropped since it is defined too > vaguely to allow anybody to write portable code by using > this exception. > (The detection of undefined variables, furthermore, is > also rather a debugging feature which should remain out > of the scope of a language standard). This have been in and out once already and the most recent view of X3J3 is in favour. It may be wanted in production code for the sake of safety. Try a straw vote in Edinburgh. I prefer to leave it in now. > > 4.4 INEXACT/INVALID: > This condition refers to general capabilities of the > processor rather than events corresponding to some > particular piece of a program; therefore, we would prefer > to drop these conditions and offer some inquiry function > for processor properties instead. No, you have misunderstood. If you are running on IEEE hardware, your program may raise such an exception. The words in the proposal are to allow other processors not to support it. > > 4.5.) GENERIC (mentioned as part of DEFAULT): > What is this condition class? Does it refer to "all user- > defined signals caused by the SIGNAL statement"? This was a mistake and has been corrected. Best wishes, John.