Arguments for or against using Try/Catch as logical operators [closed]

Question

I just discovered some lovely code in our companies app that uses Try-Catch blocks as logical operators.
Meaning, "do some code, if that throws this error, do this code, but if that throws this error do this 3rd thing instead".
It uses "Finally" as the "else" statement it appears.
I know that this is wrong inherently, but before I go picking a fight I was hoping for some well thought out arguments.
And hey, if you have arguments FOR the use of Try-Catch in this manner, please do tell.

For any who are wondering, the language is C# and the code in question is about 30+ lines and is looking for specific exceptions, it is not handling ALL exceptions.

Answer 1

Exception handling tends to be an expensive way to handle flow control (certainly for C# and Java).

The runtime does quite a lot of work when an exception object is constructed - getting the stack trace together, figuring out where the exception is handled and more.

All this costs in memory and CPU resources that do not need to be expanded if flow control statements are used for flow control.

Additionally, there is a semantic issue. Exceptions are for exceptional situations, not for normal flow control. One should use exception handling for handling unanticipated/exceptional situations, not as normal program flow, because otherwise, an uncaught exception will tell you much less.

Apart from these two, there is the matter of others reading the code. Using exceptions in such a manner is not something most programmers will expect, so readability and how understandable your code is suffer. When one sees "Exception", one thinks - something bad happened, something that is not supposed to happen normally. So, using exceptions in this manner is just plain confusing.

Answer 2

I just discovered some lovely code in our companies app that uses Try-Catch blocks as logical operators. Meaning, "do some code, if that throws this error, do this code, but if that throws this error do this 3rd thing instead". It uses "Finally" as the "else" statement it appears. I know that this is wrong inherently...

How do you know that? I gave up all that sort of "knowledge" and now just believe that the simplest code is the best. Suppose you want to convert a string to an Optional which is empty if the parse fails. There is nothing wrong with:

try { 
    return Optional.of(Long.valueOf(s)); 
} catch (NumberFormatException) { 
    return Optional.empty(); 
}

I completely disagree with the usual interpretation of "Exceptions are for exceptional conditions". When a function cannot return a usable value or a method cannot meet its post-conditions, throw an exception. It doesn't matter how often these exceptions are thrown until there is a demonstrated performance problem.

Exceptions simplify code, by allowing the separation of error handling from the normal flow. Just write the simplest possible code, and if it is easier to use try-catch or to throw an exception, then do that.

Exceptions simplify testing by reducing the number of paths through the code. A function with no branches will either complete or throw an exception. A function with multiple if statements to check for error codes has many possible paths. It is very easy to get one of the conditions wrong, or to forget one completely, so that some error condition is ignored.

Answer 3

Debug and maintenance work is very difficult when control flow is performed using exceptions.

Inherently, exceptions are designed to be a mechanism for altering the normal control flow of your program - of performing unusual activities, causing unusual side-effects, as a way to get out of a particularly tight bind that can't be handled with less complicated means. Exceptions are exceptional. This means that, depending on which particular environment you're working in, use of exception for regular control flow can cause:

• Inefficiency The additional hoops that the environment has to jump through to safely perform the relatively difficult context changes required for exceptions require instrumentation and resources.

• Debug difficulties Sometimes useful (when trying to debug a program) information gets thrown out the window when exceptions occur. You can lose track of program state or history that's relevant for understanding run-time behavior

• Maintenance problems Execution flow is hard to follow through exception jumps. Beyond that, an exception may get thrown from inside black-box type code, which may not behave in easy to understand ways when throwing an exception.

• Poor design decisions Programs built in this manner encourage a frame of mind which, in most cases, doesn't easily map to solving problems elegantly. The complexity of the final program discourages the programmer from understanding fully its execution, and encourages taking decisions which lead to short-term improvements with high long-term costs.

Answer 4

I've seen this pattern used several times.

There are 2 major problems:

• It's extremely expensive (instantiation of the exception object, gathering the call stack etc.). Some compilers might actually be able to optimize it away, but I wouldn't count on that in this case, because exceptions are not intended for such use, therefore you can't expect people to optimize for it.
• Using exceptions for control flow is in fact a jump, much like a goto. Jumps are considered harmful, for a number of reasons. They should be used, if all the alternatives have considerable disadvantages. In fact, in all my code I recall only 2 cases, where jumps were clearly the best solution.

Answer 5

Sometimes exceptions are fastest. I've seen cases where null object exceptions were faster even in Java than use of control structures (I cannot cite the study at the moment, so you'll have to trust me). The problem comes in when Java has to actually take the time and populate the stack trace of a custom exception class instead of using native ones (which seem to be at least partially cached). Before saying that something is unilaterally faster or slower, it would be good to benchmark.

In Python it is not only faster, but it is much more correct to do something which might cause an exception and then handle the error. Yes, you can enforce a type system, but that goes against the philosophy of the language -- instead you should simply try to call the method and catch the result! (Testing whether a file is writable is similar -- just try writing to it and catch the error).

I've seen times when it is faster to do something stupid like query tables which weren't there than to figure out whether a table exists in PHP+MySQL (the question where I benchmark this is actually my only accepted answer with negative votes).

All of that said, use of exceptions should be limited for several reasons:

1. Accidental swallowing of nested exceptions. This is major. If you catch some deeply nested exception which someone else is trying to handle, you have just shot your fellow programmer (maybe even you!) in the foot.
2. Tests become non-obvious. A block of code which has an exception in it could have one of several things wrong with it. A boolean, on the other hand, while theoretically it could be annoying to debug, it generally isn't. This is especially true as the try...catch control flow adherents generally (in my experience) do not follow the "minimize code in try block" philosophy.
3. It does not allow for an else if block. Enough said (and if someone counters with a "But they could use different exceptions classes", my response is "Go to your room and don't come out until you've thought about what you've said.")
4. It is grammatically misleading. Exception, to the rest of the world (as in not adherents to the try...catch control-flow philosophy), means that something has entered an unstable (though perhaps recoverable) state. Unstable states are BAD and it should keep us all up at night if we actually have avoidable exceptions (it actually creeps me out, no lies).
5. It is not compliant with common coding style. Our job, both with our code and with our UI's is to make the world as obvious as possible. try...catch control-flow goes against what are commonly considered best practices. This means it takes more time for someone new to a project to learn the project, which means an increase in the number of man-hours for absolutely no gain.
6. This often leads to code duplication. Finally blocks, though this is not strictly necessary, need to resolve all of the dangling pointers which were left open by the interrupted try block. So do try blocks. This means you can have a try{ obj.openSomething(); /*something which causes exception*/ obj.doStuff(); obj.closeSomething();}catch(Exception e){obj.closeSomething();}. In a more traditional, if...else scenario, the closeSomething() is less likely (again, personal experience) to be a copy and paste job. (Admittedly, this particular argument has more to do with people I have met than the actual philosophy itself).

Answer 6

My main argument is that using try/catch for logic breaks the logical flow. Following "logic" through non-logic constructs is (to me) counter-intuitive and confusing. I'm used to reading my logic as "if Condition then A else B". Reading the same statement as "Try A catch then execute B" feels weird. It would be even weirder if statement A is a simple assignment, requiring extra code to force an exception if condition is false (and doing that would probably require an if-statement anyway).

Answer 7

Well, just a matter of etiquette, before "starting an argument with them", as you state it, I would kindly ask "Why they use exception handling in all these different places?"

I mean, there are several possibilities:

1. they are incompetent
2. there is a perfectly valid reason for what they did, which may not appear at first sight.
3. sometimes it is a question of taste and may simplify some complex program flow.
4. It's a relic of the past that nobody changed yet and they'd be happy if someone does it

...I think all of these are equally likely. So just ask them nicely.

Answer 8

Exception are for when Exceptional thing happen. Is the program functioning according to regular workflow exceptional?

Answer 9

Reason to use exceptions:

1. If you forget to catch an exceptional circumstance, your program will die and the stack trace will tell you exactly why. If you forget to handle the return value for an exception circumstance there is not telling how far away your program will exhibit incorrect behavior.
2. Using return values only works if there is a sentinel value you can return. If all possible return values are already valid, what are you going to do?
3. An exception will carry additional information about what happened which may be useful.

Reasons not to use exceptions:

1. Many languages aren't designed to make exceptions fast.
2. Exceptions which travel several layers up the stack can leave inconsistent state in their wake

In the end:

The goal is to write code that communicates what is going on. Exceptions can help/hinder that depending on what the code is doing. A try/catch in python for a KeyError on a dictionary reference is perfectly (as long as you know the language) try/catch for the same KeyError five function layers away is dangerous.

Answer 10

Try Catch should only be used for exception handling. More so, especific exception handling. Your try catch should catch only expected exceptions, other wise it is not well formed. If you need to use a catch all try catch, then you are probably doing something wrong.

EDIT:

Reason: You can argue that if you use try catch as a conditional operator, How are you going to account for REAL exceptions?

Answer 11

I use try->catch as flow control in certain situations. If your primary logic depends on something that fails, but you don't want to just throw an exception and quit...That's what a try->catch block is for. I write a lot of unmonitored server-side unix scripts, and its far far more important for them not to fail, than it is for them to fail prettily.

So try Plan A, and if Plan A dies, catch and run with Plan B...And if plan B fails, use finally to kick off Plan C, which will either fix one of the failed services in A or B, or page me.

Answer 12

It depends on the language and maybe on the implementation being used. The standard in C++ is that exceptions should be saved for truly exceptional events. On the other hand, in Python one of the guidelines is "it is easier to ask for forgiveness than for permission", so the integration of try/except blocks in program logic is encouraged.

Answer 13

It is a bad habit, but I do it from time to time in python. Like instead of checking to see if a file exists I just try and delete it. If it throws an exception, I catch and just move on knowing that it wasn't there. <==(not necessarily true if another user owns the file, but I do it in a user's home directory so this SHOULDN'T happen).

Still, overused it's a bad practice.

Answer 14

I like the way Apple defines it: Exceptions are only for programmer errors and fatal runtime errors. Else use error codes. It helps me to decide when to use it, thinking to myself "Was this a programmer error?"

Answer 15

This sounds like using exception handling to build goto logic on top of a language that doesn't have a goto command.

For the many reasons why goto logic is bad, you can refer to this question: https://stackoverflow.com/questions/46586/goto-still-considered-harmful