NICE Eiffel Standards Group -- Library Committee Mailing List To post to list: NICE-ESG-Libs@atlanta.twr.com To send mail to the Chairman of the committee: NICE-ESG-Libs-chair@atlanta.twr.com Administrative matters (sign up, unsubscribe, mail problems, etc): NICE-ESG-Libs-request@atlanta.twr.com
Date: Sat, 25 Nov 1995 15:21:35 GMT From: Roger Browne <rogerb@eiffel.demon.co.uk> Subject: Exceptions To: NICE-ESG-Libs@atlanta.twr.com In NICE-ESG-Libs Digest #306, Frieder Monninger wrote: > 1. to give raise 4 parameters > (2 strings, one integer and one object) > > Reason: > this gives more flexibility to produce good error messages - > and if the parameters are not necessary one can use void ... > It seems to be a good compromise between 0 and unlimited - at least > in Eiffel/S it was usefull all the time. > One parameter is definetively not enough - and 10 are to clumsy. I certainly found the Eiffel/S exception parameters to be a good design compromise between too many and too few. But why compromise at all? If EXCEPTION is going to be changed for the next vintage, why not make it object-oriented? For example, we could have this kind of inheritance heirarchy: EXCEPTION (deferred) MATH_EXCEPTION DIVIDE_BY_ZERO INTEGER_OVERFLOW REAL_OVERFLOW (etc) ASSERTION_FAILURE PRECONDITION_FAILURE INVARIANT_FAILURE (etc) HARDWARE_ERROR DEVICE_NOT_READY FILE_ERROR READ_ERROR WRITE_ERROR OUT_OF_MEMORY (etc) OPERATING_SYSTEM_SIGNAL INTERRUPT_SIGNAL BREAKPOINT (etc) USER_DEFINED_ERROR (etc) Then, 'raise' needs only one parameter - an EXCEPTION object. The descendants of EXCEPTION can have creation features with any number of parameters, and the exception handler can use assignment attempt to handle exceptions at any desired level of generality (e.g. the same handling for all assertion failures, or specific handling for precondition failure). As a fringe benefit, we can make the upper (general) part of the EXCEPTION heirarchy platform-independent, so that cross-platform code may be written wherever possible, yet platform-specific exceptions may also be caught. With the existing mechanism, we can only attempt platform-independence by choosing a semi-arbitrary subset of exception codes. What do committee members think? Regards, Roger -- -- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525 -- Everything Eiffel: compilers/libraries/publications | +44-1772-687525
Date: Sat, 25 Nov 1995 22:27:17 GMT From: Roger Browne <rogerb@eiffel.demon.co.uk> Subject: Proposal RB-1: Remove note from HASHABLE To: NICE-ESG-Libs@atlanta.twr.com Christine wrote: > Current discussions in the committee fall into 3 categories > (in priority order): > > 1. Outstanding issues with ELS95. > 2. Suggestions for changes to ELS95 to be incorporated into ELS96. > 3. Discussion about Donated Libraries and the role that NICE > and this committee should play in sponsoring and promoting them. > ... > As we now have a published standard, any changes to the document should > be discussed and voted on, even if they appear to be relatively minor > (matters of style, typos etc.,). Welcome back, Christine! Let me start the ball rolling by re-posting a previous proposal, which I discussed in NICE-ESG-Libs Digest #280, 23 July 1995: ===== Tag: RB-1: Remove note from HASHABLE Class: HASHABLE Proposed Change: That the "note" in the indexing clause be removed. Details: Remove the following text from the indexing clause of HASHABLE: note: "In general, the default value of a type (e.g. 0 for integers, void for references) may not be hashed." Rationale: The preconditions to 'hash_code' which supported this note in other revisions of HASHABLE do not appear in the ELS95 document, therefore it seems to me that the inclusion of this note in ELS95 is an oversight. Certainly, a hash code is much less useful if it cannot be computed for default values. Migration strategy: No known problems. Any existing system should continue to work correctly. -- -- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 01772-687525 -- Everything Eiffel: compilers/libraries/publications | +44-1772-687525
