Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Paul Clapham
  • Jeanne Boyarsky
  • Ron McLeod
  • Frank Carver
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
  • Piet Souris
  • Frits Walraven
  • fred rosenberger

assertion strategy

Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

Replace the word "snake" with "danger noodle" in all tiny ads.
the value of filler advertising in 2021
    Bookmark Topic Watch Topic
  • New Topic