howard@maccs.dcss.mcmaster.ca (Howard Betel) (02/28/90)
I'm an undergrad who is taking a 4'th year MIS course. Our text for the
course is OBJECT-ORIENTED SOFTWARE CONSTRUCTION by Betrand Meyer. The
way the course is working is that each person gives an approximately
1.5 hour seminar on part of a chapter. Mine was 7.9 to the end of the
chapter. I had a question from the class that I wasn't sure of the
answer, so here goes.
Meyer states on page 168 (7.10.3)
"Another way to express the same remark is to say that an operation
may only succeed or fail; there is no middle ground. (Trivial as
this comment may seem, it is not satisfied by the exception
mechanisms of such languages as ADA, CLU or PL/I, which make
it possible to exit from a routine without achieving the routine's
intent, and without signalling failure to the caller."
Now I really do understand the importance of this (and the logic) however
since the assertion defaults are:
"NO_ASSERTION_CHECK (Y):
PRECONDITIONS (Y): ALL
ALL_ASSERTIONS (Y):"
doesn't this allow failures? If a function is executing and the
postconditions are not met, it is possible for a function to complete
with a failure and the client not know that this occured. Not only
does this seem possible, it seems probable considering that by default
postconditions are not checked.
Any answers?
--
Howard Betel Howard@maccs.dcss.McMaster.CA
Dept of Computer Science ...!unet!utai!utgpu!maccs!howard
McMaster Universitymarcap@hercule.cs.concordia.ca (PAWLOWSKY marc) (03/01/90)
In article <25EB6B0D.2249@maccs.dcss.mcmaster.ca> howard@maccs.dcss.mcmaster.ca (Howard Betel) writes: ... >Meyer states on page 168 (7.10.3) > "Another way to express the same remark is to say that an operation > may only succeed or fail; there is no middle ground. ... >Now I really do understand the importance of this (and the logic) however >since the assertion defaults are: > "NO_ASSERTION_CHECK (Y): > PRECONDITIONS (Y): ALL > ALL_ASSERTIONS (Y):" ... >doesn't this allow failures? If a function is executing and the >postconditions are not met, it is possible for a function to complete >with a failure and the client not know that this occured. ... You are correct in that a function could fail and not tell its caller. This is essentially an eiffeciency issue. For often the checking is quite time consuming. For example I just wrote a class to perform quick_sort. The properly check that the procedure has worked it is necessay to check that the cardinality is still the same, all objects that entered the array exit the array, the output is sorted. When an object is "put" into a structure it should also be checked that the object is in the structure. While this was fine for debugging, it slows down production programs too much. For example a program that took over an hour with all assertions took around 10 minutes when the assertions were turned off. Marc Pawlowsky Grad Student Concodia University