File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes assertion strategy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "assertion strategy" Watch "assertion strategy" New topic

assertion strategy

Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I am using assertions in my program at places to throw errors that will alert me to problems. This is accomplished by way of the runtime exception shuttinng down whatever was in process and me noticing that something terribly wrong has taken place. This is not something I want to happen when the application is released.

Should I create my assertions in such a way that their enabling or disabling does not alter the behavior of my program? That does not seem right, but it feels odd to have a program that becomes much more restrictive when assertions are on. Or I have to make darn sure they can not be turned on at the customer.

Any thoughts about this?
Kai Witte
Ranch Hand

Joined: Jul 17, 2004
Posts: 356

in Swing applications I handle uncaught exceptions like this, run on startup:

(SwingTools.exceptionDialog shows one of these typical error messages with a "Details" button. The "Details" button would show the full stack trace. I plan to release the entire SwingTools for years but never find the time.)

Thanks to a high test coverage and best exception handling practices this dialog has never ever been seen by any end user. If anything should happen it is good to know that the user would get an error message that helps as much as possible, both him and me, in that dire situation.

So far to Swing only.

In a typical J2EE application the best still is to let the unexpected exception (or AssertionError) happen. An error-page configured in the DD can show something appropriate for web clients and also notify the admin. This will usually never happen.

In a critical embedded/realtime system it often is best to recover even from programming errors. Languages like Ada support this directly. Usually that is not the way to go, though.

If you are really using the assert keyword: That is problematic anyway. It is elegant and looks good, but since you can't guarantee that assertions are enabled at runtime it might be best to make your own assertTrue method or whatever.

And in any case you must never assume in the program logic that the assert statement is evaluated. E. g. never change a variable in the assert condition.


Kai Witte's business website Kai Witte's private homepage
I agree. Here's the link:
subject: assertion strategy
It's not a secret anymore!