I think that's the same thing functionality-wise since you can also
specify messages in asserts. Another thing w/ asserts is that you
can turn them off if you want to go into "damn the torpedoes" mode.
With that said, I personally prefer to have our own assert class w/ a
set of assert methods that would make it more clear to the reader what
it is that we're concerned about.
Regards,
Alan
On Oct 5, 2009, at 10:18 AM, Donald Woods wrote:
Why not just throw a RuntimeException, with an informative message
as to what the invalid value was and what was expected? We use that
method over asserts all the time in OpenJPA.
-Donald
Alan D. Cabrera wrote:
I wouldn't say that one is better than the other. I think that
both have their places.
I use assertions to catch catastrophic conditions early on. Note
that I use the word catastrophic. The idea is that if you get
values that are known a priori to be bad and will definitely cause
the server to barf it's better to complain right then and there
rather than complain at some later point in time when the server
tries to use them.
Regards,
Alan
On Oct 5, 2009, at 2:09 AM, David Bosschaert wrote:
I guess I don't mind this but I wonder what you are trying to
achieve? I
mean, you have a running system and all of a sudden you get an
assertion
failure. What are you going to do?
I always wondered whether code assertions are really the right
tool for the
job...
In my opinion it would be better to add a bunch of unit tests to
the system
and put all your assertions in there. That way your assertions are
part of
the continuous build & test cycle and when there is an assertion
failure you
will actually have the opportunity to do something about it: fix
the code
and rerun the tests...
Best regards,
David
2009/10/3 Alan D. Cabrera <[email protected]>
Does anyone mind if I start putting in assert statements in the
code?
Regards,
Alan
