Exception messages....how do YOU eat yours??

Question

Exception Messages - For user or developer?
Summary
When catching Exceptions, is/should it be necessary to look at the message String for deciding what action should be taken or is the message just for humans?
What is the generally accepted use of Exception messages - user messages, or for deveopers and program parsing?
Details
Exceptions generally contain some kind of 'useful' message.
As we are developing our programs we, as developers, might be able to use this message to help diagnose problems.
But once we've finished development and come to deploy our program we will, of course, be catching all possible Exceptions so that the user does not get thrown out of the program in a very undignified manner.
When catching these Exceptions, what 'should' be done with it?
Wrap it up as a neat little Error message for the user?
Or are they there for programs to 'read' themselves and decide what to do next depending upon the potentially dynamic message String?
thanks,
John
([email protected])

Answer 1

In addition, when you start thinking about parsing exception messages to further determine the facts behind the exception, it makes me wonder if you aren't forgetting to check your variables to further determine the problem, and also to take advantage of defining your own custom exceptions to further refine your handling of the errors that are unique to your program.
Let me give a cheesy (and purely conceptual) example to describe what I mean.
Your program is simulating cooking pizza's, let's say. At the end of the baking process, you catch an array index out of bounds exception as a basic beginning.
Now, upon finding something unexpected wrong with the array of pizzas that you were expecting from the oven (within the catch block), you check for the conditions that help you refine your understanding of what went wrong.
So, you test 'was the array null?' ...which means nothing at all came out of the oven, in which case you throw your custom "OvenWayToHotException", with a warning for the cook to turn down the heat. If the array was NOT null, but just had less values than you expected ...you can then throw your "PizzaLeftBehindInOvenException", with a warning for the cashier to go check the oven because someone forgot a pizza inside. These further refined exceptions are then thrown up the chain to the portion of your code that presumed to cook the pizzas properly before giving them to the customer.
In the end, the message to either �check the oven for missing pizzas� or �apologize to the customer while they wait for you to redo their whole order� will be a lot more informational than �ArrayIndexOutOfBoundsException at method cookPizzas()�
I realize this might be a cheesy example, but maybe it demonstrates a technique for using base exceptions as a beginning point for determining programmatically what went wrong, and then handling it from there. Further inspection of variables is more likely how your program will figure out what went wrong rather than parsing the message in the rare case that it contains unique information. You, who wrote the program, usually know exactly what it means when certain groups of variables are found in certain states. Exceptions are a way to avoid doing a bunch of unnecessary tests until you get an indication that these tests are actually required in the first place.
Of course, having said that, you are also free to be creative when you design code ...so if what you are doing works better than any other approach you can think of ...then using any idea you can cobble together is probably better than throwing the program in the trash bin, wouldn't you say?