Re: Modular Protection vs Assertions ...

Exceptions are used to handle cases where the failure result could not
have been predicted beforehand.  A network communications failure
cannot be tested for and you can only observe its occurrence once it
has happened.

Contracts are used to reduce the domain and range of a function in to
terms valid for that function.  A range constraint on the function
is_even(source: INTEGER) would be result implies source \\ 2 = 0.  A
domain constraint on the function sqrt(source: REAL) would be source >
0.  It can be determined beforehand that source should should not be
negative or that an even number should have no remainder when divided
by two.

Contracts should be fleshed out in debugging and testing.  Exceptions
can occur during normal program execution and should be anticipated
and able to recover but only used to recover from things that could
not have been tested beforehand.

I hope that clears up their distinct uses.

On Jul 28, 8:40 am, bravegag <brave...@[EMAIL PROTECTED]
> wrote:
> 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".
>
> - 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.
>
> 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"
seehttp://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
> 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.
>
> 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.
>
> TIA,
> Regards,
> Giovanni