public static void ValidateData() {
try {
ValidateDataInner();
} catch (Exception e) {
throw e;
}
}
Since I've seen this exact thing several times in the codebase today, I'm wondering if maybe it has some kind of magical benefit or side-effect that I'm not aware of. The only benefit that I can think of is that an unintelligent programmer can claim to be programming "defensively", or something like that.
As written here, it obviously has no purpose at all. But slightly modified, I can think of at least two cases where I use it.
ReplyDelete1. Converting checked exception to unchecked -- applicable only to languages distinguishing checked and unchecked exceptions.
public void validateData() {
try {
doValidateData(); // throws Exception
} catch (Exception e) {
throw RuntimeException(e);
}
}
2. Logging or some other exception processing.
public void validateData() throws Exception {
try {
doValidateData(); // throws Exception
} catch (Exception e) {
log.warn("failed", e);
throw e;
}
}
The advantage is very little, but it is there -- separating exception processing from "real meat". Not extremely important, but I kinda like it this way.
Yes, you're right. re-throwing isn't a bad thing, so long as you make som kind of change. Throwing the exact same exception in the exact same way is never useful
ReplyDeleteA coworker of mine justifies this as documentation that the code might throw an exception. He says it's good practice to indicate to future programmers that you knew about possible exceptions but decided explicitly not to deal with them.
ReplyDeleteI'm not entirely convinced, because my assumption is that any code can throw exceptions at any time. Which means you have to put try/catch everywhere?