There are always exceptions to the rule, right? In Java, those exceptions allow a clean break from normal program flow in the event of an exceptional situation. They're not used for program flow interruption, but for program flow branching, which can sometimes lead to difficult-to-maintain code. Marcus Zarra walks you through several best practices for using exceptions in Java.
To read all comments associated with this story, please click here.
Member since:2005-11-11
"Stupid article written by a stupid person."
Wow, spoken like a true scholar, I am right, anyone who thinks different is stupid.
I believe you are wrong. It's a pretty good article, not perfect, but hardly "stupid." It's not an article about good naming convention, it's about exceptions. And even so, some people would disagree with your naming convention. I think your working with the wrong language (Java) if you want all your statements to equate to perfectly logical English sentences. I wouldn't want my code overrun with function names like "attemptToChargeCustomerCard." "chargeCustomerCard" adequately describes the purpose function. The function name doesn't need to hint at how it works. Javadoc comments should describe the return value and any possible exceptions, not the function name. Lets say we do it your way
if (attemptToChargeCustomer()) {...} else...
It's still ambiguous. Does false mean we couldn't contact their bank or that it was denied. Do exceptions occur when we can't contact the bank? We still need to double check the Javadocs(api docs) to see what false means exactly and what exceptions could arise.
"it advocates returning false if the customer's credit card cannot be charged. That's an exception! If the method was called "attemptToChargeCustomer" it would be acceptable to return true on success and false on failure, but it isn't."
His use of a return value is good design with either function name. An exceptional event is "anything that is outside of the expected scope." Not charging the card is a completely possible outcome, its not an exception!
a good example from the article
In this context, I define an exceptional event as anything that is outside of the expected scope. If you are verifying the results in a text field, and the text field requires only numbers, a letter is not an exceptional result. That should be expected behavior. Wrong, but expected. In this situation, it is better to return an error code instead of throwing an exception.
If the situation is completely unrecoverable, it is proper to throw an exception. What is considered unrecoverable? It naturally depends on the situation, but in some cases, disk errors or network failures would be good places for the use of an exception.
Edited 2005-12-26 06:12
Member since:2005-06-29
The author is trying to make the point that you shouldn't use exceptions to branch your code, but to handle serious errors.
I think the idea is that chargeCustomerCard failing is a realistic event that the programmer needs to deal with to run his easy set of tests. This:
if (!chargeCustomerCard()) {
....
}
Is a lot prettier than this:
try {
chargeCustomerCard();
}
catch (Exception e) {
...
}
It's simply far easier to read. Especially if you have a function which makes 12 of these types of calls with many of them nested. Nested try/catch blocks aren't pretty to read.
Member since:
2005-07-06
The very first example advocates using a boolean return value on a method that does complex work. Specifically, it advocates returning false if the customer's credit card cannot be charged. That's an exception! If the method was called "attemptToChargeCustomer" it would be acceptable to return true on success and false on failure, but it isn't. The method is called "chargeCustomerCard" and that's what it should do. If it can't do what its name says it will then an exception has occured and the caller should be free to catch it or pass it up. Stupid article written by a stupid person.