Path: utzoo!attcan!uunet!mcsun!ukc!pyrltd!tetrauk!rick From: rick@tetrauk.UUCP (Rick Jones) Newsgroups: comp.object Subject: Re: Should a constructor do "work"? Message-ID: <525@tetrauk.UUCP> Date: 19 Jul 90 09:37:12 GMT References: <55236@microsoft.UUCP> <519@tetrauk.UUCP> <364@eiffel.UUCP> Reply-To: rick@tetrauk.UUCP (Rick Jones) Organization: Tetra Ltd., Maidenhead, UK Lines: 53 In article wex@dali.pws.bull.com (Buckaroo Banzai) writes: >In article <364@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: >> If invariants are checked and a creation operation raises >> an exception, the target of the Create should remain void, >> excluding any creation of an inconsistent object. > > ... > >Suppose then that some of the initialization fails. Can't I write a >specification that says "the value will be a list of numbers or NULL"? Then >when the initialization fails, I can return an object with that particular >slot having a NULL value. > >This would fulfill the specification; are you saying that this would not >"raise an exception" in the sense that you mean it above? This all comes down to being clear about what is and is not a valid state for the object, i.e. what the invariant condition is. You have effectively defined your invariant in the statement above by saying that a null list is a valid state. This is quite OK provided that the routines of the class are written to take account of the possibility of a null list, and so creating such an object would not raise an exception. The other approach is to say that your class routines are NOT going to tolerate a null list, and that you don't allow any such object to exist. This then raises the above problem in that a failure to create the list when creating the containing object is BY DEFINITION an exception condition. Apart from the general issue of exception handling, the special case of an exception during object creation should result in no object being created, and any associated reference remaining void. The choice of how to handle the situation is one of design, and one or other may be appropriate for different problems. However, I think the ability to clearly define and correctly handle exception conditions is a very valuable one, and if properly used can considerably simplify programs. There is some statistic about how much of a typical program is devoted to handling error conditions; I forget what it is but it's a large number. This seems to result from all the code which appears as in-line logic to handle what in reality are exceptions to normal execution. What is and is not an "error" gets very confused. I am using Eiffel, and planning to make maximum use of it's exception handling to deal with everything which is not a normal down-the-middle expected situation (at least at the prototype stage). This includes things which are not normally treated as errors, such as "record not found" on file access, or "wrong entry" at a terminal. This could be a good subject for discussion; has anyone any experience of taking this approach to building software? -- Rick Jones You gotta stand for something Tetra Ltd. Maidenhead, Berks Or you'll fall for anything rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick) - John Cougar Mellencamp