Regarding exceptions.... They're probably the best way to deal with errors... much better than error return codes etc... I'm saying that you shouldn't need to have try/catch blocks everywhere.
i agree totally with what you(mohn) says. even on the one gui app i've worked on there just too many try/catch blocks everywhere...
i wanted to focus on assertions actually.
The way I think about them is... assertions are for programmers, exceptions are for users. If you are coding and you have an assertion that fails, the program will halt and tell you where the error is. But you don't want the user to see that. You want an exception and a nice user friendly message.
are you trying to imply that assertions should be used only for debugging? i read this article Part 2: impact of Java's new assertion facility . i got the feeling that the author suggests the use of assertions not for debugging but for general application working. please correct me incase. and let me know how you use assertions and what do you make of this article? i understand that even though you might use assertions, eventually have to use try/catch blocks for AssertionError Exception to finally use the assertion, might increase lines of code. but do you think it will look better? conforming to the Design by Contract? being as lazy as i am i did not read on the DBC design, but sounds good. what do you feel.
Even better is to have a class invariant. That's basically a method in each class that checks that the data is in a valid state....
could you provide an example for the above design? would help in understanding much better.