Assertions vs Exceptions ...
Giovanni Azua
I am developing a framework in Java and facing the question of whether:
- Provide a defensive layer around my framework as part of the API public
contract e.g. throws IllegalArgumentException on invalid input or
"precondition violations".
Pros)
> Clear client-provider contract.
> Allows possible recovery in production mode.
Cons)
> Performance
- Do not provide any defensive layers but instead use assertions, so users
of my framework have the following options:
a) enable assertions during testing and debugging.
b) disable assertions once in production mode at the cost of
possible production faults because of unrecoverable
"precondition violations" that could lead to infite recursions
or the like.
Pros)
> Performance.
Cons)
> Preconditions are not part of the public interface contract.
> No chance to recover from precondition violations in
production mode.
I posted a thread "Modular Protection vs Assertions" in the following
newsgroup where I include different views on the subject from either Sun
guideliness on assert usage vs guideliness proposed by top figure in OO
Prof. Dr. Bertrand Meyer see:
Any insights?
Which solution would YOU prefer if you were to be the user of a framework?
Best regards,
Giovanni
Thomas Hawtin
>
> - Provide a defensive layer around my framework as part of the API public
> contract e.g. throws IllegalArgumentException on invalid input or
> "precondition violations".
> Cons)
> > Performance
>
> - Do not provide any defensive layers but instead use assertions, so users
> of my framework have the following options:
In practice argument checking does is very rarely a performance issue.
It's used in low-level APIs and even arrays. High-level checks should
usually be much less frequent than these.
OTOH, the improvements in programmer productivity and being able to
detect errors in live systems is very important. It's a pity more isn't
done be static analysis.
Tom Hawtin
Giovanni Azua
"Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message:
> "Giovanni Azua" <brav...@hotmail.com> writes:
>>Cons Preconditions are not part of the public interface contract.
>
> Why can't they be listed in the public interface
> contract in this case?
>
Well, if you mean you can document assertions in Javadoc, in the Javadocs
you may write whatever you want but Javadocs and the (sad) reality may be
different or become obsolete anytime. Conversely the throws clause e.g.
throwing checked exceptions is part of the method signature and "public
contract".
Regards,
Giovanni
PS: anyway which solution would you prefer? :)
Lew
The conventional wisdom is that assertions are to enforce invariants, and
these are under API developer control. Sun and others explicitly advise
against using assertions for data validation. Heed this advice.
Exceptions, particularly checked exceptions and not runtime ones as you
illustrate, exist for the purpose you describe.
--
Lew
Mark Rafn
>I am developing a framework in Java and facing the question of whether:
>
>- Provide a defensive layer around my framework as part of the API public
>contract e.g. throws IllegalArgumentException on invalid input or
>"precondition violations".
Do that. Be very clear in documentation what you expect of your callers, and
check your state and parameters in ways that are clear to callers.
> Pros)
> > Clear client-provider contract.
> > Allows possible recovery in production mode.
>
> Cons)
> > Performance
Generally, not much of a con. Where something is so tight that you really
can't afford parameter validation, you should usually go with a pattern where
there's a call that does a lot of validation which returns a pre-validated
object that can rapidly be reused many times. But generally, just program
defensively at interface boundaries.
>- Do not provide any defensive layers but instead use assertions, so users
>of my framework have the following options:
Yick. Asserts are for turning a hidden bug into an explicit one, and work
best for the person controlling the code. Don't base your API behavior on
assertion status of your classloader.
You left out:
- Provide a defensive layer around your framework AND use assertions inside
your code to protect yourself against bugs or unexpected situations.
--
Mark Rafn da...@dagon.net <http://www.dagon.net/>
Ben Phillips
> "Giovanni Azua" <brav...@hotmail.com> writes:
>
>>>>Cons Preconditions are not part of the public interface contract.
>>>
>>>Why can't they be listed in the public interface
>>>contract in this case?
>>
>>reality may be different or become obsolete anytime.
>
>
>
> A method »log«, requiring x > 0, could be written as:
>
> double log( final Positive x ){ ... }
Bleeaaccchhhkk!
A whole new class just for this?
What we really need is for Java 7 to add eiffel-style invariants and
suchlike. Preconditions are specified with a string literal optional and
throw IllegalArgumentException, or maybe NullPointerException for "!=
null" ones. The others throw Error, because they surely indicate a bug
in the called code rather than in the calling code. Postconditions don't
trip if the code explicitly throws, of course, rather than trying to
return normally while violating a postcondition. Class invariants that
go or get left out of whack throw always -- either the class is not
exception safe or it's not thread-safe and got corrupted by a race
condition.
All of them produce javadoc entries.
I think this could be managed without new keywords, by adding a new
usage of "assert", with the risk of confusion (which asserts remain in
effect in production code?) -- the new syntax could be say
assert = precondition (foo >= 0.0 && foo <= 100.0 && foo == foo) "foo is
not a valid percentage"
assert = postcondition and assert = invariant likewise. The latter in a
class body but not a method body being a class invariant; in a loop body
a loop invariant (doesn't throw if the loop exits abnormally via break,
return, or throw).
In this case precondition, postcondition, and invariant are not
keywords; they are recognized specially after the "assert =" token pair
(currently not well-formed Java) and can be used normally as identifiers
without the usages clashing.
Twisted
Yuck. This WILL cause confusion as to which asserts are asserts and
which are in-production-code guards, regardless. Why now a new syntax
for "throw" instead? E.g.
throw = precondition (...) "..."
Ben Phillips
only in some details, not to the main idea...
Yeah, you're probably right.
> Why now a new syntax for "throw" instead? E.g.
>
> throw = precondition (...) "..."
Excellent idea. Actually, why not "throw" for precondition (throws
IllegalArgumentException and remains in production code when asserts are
disabled) and "assert" for the others, and the latter behave as special
forms of regular asserts? (i.e. throw Errors, are disabled in production
code when asserts are disabled, etc.)