bravegag <bravegag@[EMAIL PROTECTED]
> writes:
> Hi all,
>
> After reading Bertrand Meyer's OOSC book I find a little bit blurred
> the line between using proper exception declarations in public methods
> vs using asserts for precondition checking.
>
> It is confusing to me the fact that:
>
> - Bertrand remarks the need of "Modular Protection" which is not
> clearly stated but I assume it also applies to Software-to-Software
> communication i.e. between modules. Therefore module boundaries or
> module public API must rely on proper exception handling for argument
> checking and in general precondition checking (instead of using
> assertions for that purpose). I find "Modular Protection" to be
> somehow similar to "Defensive Programming".
As Meyer points out, a correct program does not pass invalid parameters
(where
the precondition would be violated). The task to find bad callers is
during
development, not during field-use. Therefore the precondition checks are
normally off. If the precondition is violated, all guarantees are lost.
The
routine _may_ raise an exception, but it's not a MUST.
>
> - On the other hand Bertrand Meyer also remarks a valid thing which is
> that excessive checking can be very harmful performance-wise.
> Therefore recommends using assertions that are enabled only during
> development, testing and debugging and disabled once the system is
> delivered in production.
Correct.
>
> Another fact is that (somehow contrary to Bertrand Meyers view) Sun
> assert usage guideline dictate that "Do not use assertions for
> argument checking in public methods" see
> http://java.sun.com/j2se/1.5.0/docs/guide/language/assert.html#usage
>
> So I can only make the conclusion that:
>
> - Assertions should be used even in public methods as long as those
> methods are not part of the public API of a module i.e. assertions are
> not an input checking mechanism for module boundaries. Bertrand Meyer
Remember: A violated assertion (like a precondition) will always terminate
the
program. Usually you cannot write a correct handler to recover from that.
You
must fix the program bug instead.
> has a section in the chapter "Design by Contract" and the headline is
> precisely that but then he remarks it is intended only for Human-to-
> Software communication or Outside-World-to-Software communication.
>
> - Proper exception handling should be the solution to use within
> module boundaries so that not only the public API of a module
> establishes a contract but also allows the client modules to
> gracefully retry or at least recover from serious faults as
> consequence of precondition violations in production time.
You can always put your "if .. then raise()" there. Eiffel has no
"Modules"
other than classes. You are suggesting that the called routine should
signal
the caller that it has made a mistake to give the caller a chance to
recover
from its error? The caller should know that it's wrong, even before
calling. That's the argumentation of Mr. Meyer I think (s/Mr./Prof. Dr./).
>
> I would greatly appreciate your feedback or insights into this subject
> or even pointers to further discussion.
>
> I have seen situations where faults may lead to a total software chaos
> just because they used assertions within module boundaries for input
> checking rather than proper exception handling.
See the Ariane case: The error output ("test pattern") of one module was
used
as valid input for another module. It would have been better if there
hadn't
been an exception at all ;-)
"He, who presses the button has the responsibility, and not the
manufacturer
of the button"
Regards,
Ulrich
|
