Menu
Is it better, less expensive or more readable to use a try/catch block in Java instead of using multiple If statements to check user input for example?
Example when parsing a Date string, won't it be better to parse directly using a try/catch block instead of writing multiple statements looking for illegal characters.
In another example, say i want to read a file or stream, instead of using Scanner, I just force the method and wait for an exception to occur.
Is that a healthy method of programming? Is it less expensive on the Virtual Machine?
UPDATE
Here is an example of what i meant when using DateFormat exception, sometimes it could be a real problem to catch an error, and when doing so, can you guarantee your complicated (usually unreadable) code is error prone?
948
In general, try-catch blocks are great because they will break (move to the catch statement) whenever the exception occurs. If-else blocks rely on you predicting when the error will happen. Edit: Also, catch blocks won't stop your code from halting when an error is hit.
In 'try-catch' the codes to handle the exceptions and what exception to be handled, that are easily readable. In 'if-else', we have one else block corresponding to one if block. Or we need to define another condition with command 'else if'. In 'try-catch' we don't have to define each 'try' block with a 'catch' block.
With a try catch, you can handle an exception that may include logging, retrying failing code, or gracefully terminating the application. Without a try catch, you run the risk of encountering unhandled exceptions. Try catch statements aren't free in that they come with performance overhead.
When you can already handle a situation before executing it, you should use if-else. But in situations where you can't know if something is going to work or not until you actually do it, use try-catch. You can't know if input is a number until you actually "try" to parse it. Hence, use try-catch.
It's a bad practice to use Exceptions for a flow control.
Some quotes:
Because exceptions are designed for use under exceptional circumstances, few, if any, JVM implementations attempt to optimize their performance. It is generally expensive to create, throw, and catch an exception.
In the presence of an unrelated bug, the idiom can fail silently and mask the bug, greatly complicating the debugging process.
Update: As it's said (and I remember that I also found the same statement in Josh Bloch's blog) using exceptions for flow control is like using GOTOs for the same purpose. You can read interesting Dijkstra article about why GOTOs are bad.
165
In general, exceptions are meant for... well, exceptional events. If is meant for things that can occur during the normal course of events.
So typically, if you want to handle a case for which you don't have a good local solution, use an exception to propagate it upwards to someone who can deal with it better. This is significantly more costly than if-else, that's one more reason not to abuse it. A third, IMHO equally important concern is readability: it is much more difficult to follow where the execution flow continues after a throw, than to read a sequence of if statements.
If you want to handle a case locally, most of the time it's better to use a simple if.
23
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
