What cannot be done with the else clause, and can be done with exception handling?

Question

what cannot be done with the if else clause and can be done with exception handling?

In other words, where do we really need to use exception handling and simply if the other will not serve the purpose.

Is exception handling the only glorified way to display errors?

Answer 1

In the earliest C ++ implementations, exceptions were compiled into equivalent if / else constructs, more or less. And they were slow, like molasses, to the extent that you can still find programming guides that recommend the exception because "they are slow."

So this is not a question of "can" or "can not." It's about readability and performance.

Slowing down each line of your code with error checking makes it harder for a person to follow an unreasonable (i.e., common) case. And, as every good programmer knows, the main audience for your code is human readers.

In terms of performance, if / else is slower than the current exception implementation. Modern implementations carry literally zero overhead, unless the exception is actually thrown. If your exceptions are truly “exceptional” cases, this can be a significant difference in performance.

Answer 2

Some languages ​​(e.g. C ++) do not allow returning values ​​in some cases. For example, in C ++ constructors there are no return values ​​(even void ), therefore the only way to signal an error in the constructor is an exception.

Answer 3

See that you cannot do anything with exceptions that you cannot do with the 8086 manual encoded assembler. (Turing is complete!) Except that manual coding assembler is not a good tool for a 100K line project if you are not the best encoder in the Milky Way, if so. Experience has shown a number of situations where the idiom of exception handling provides the most reliable code written by ordinary people. Good example ctors. That is, errors that need to be propagated in the call stack. Edit: And how many people really verify that malloc will not work every time? It is better to throw an OutOfMemoryException.

Answer 4

Exceptions are what they are called for: Exceptional events or situations that disrupt the current thread.

You should use exceptions to indicate that something unpleasant and very unusual has happened. Say you have a class that reads your configuration file. Exceptions may include:

• File not found.
• The file exists but cannot be read.
• The file was deleted in the middle of a read operation.

You could handle all this with if-else blocks, but it’s much easier to do with exceptions.

Answer 5

Of course, you can write code that does not use exceptions. However, if you do, you would make sure that any function that might throw an error is handled properly.

For me, the biggest advantage of having exceptions is that I can write direct code that simply assumes that all functions succeed, knowing that the upper levels will take care of error messages.

Specifically, take the following dummy function for working with text in the editor:

 do-stuff: backward-line 10 x = point search-for "FOO" return buffer-substring x point 

Both the return line and the search can fail. If I had to handle the errors myself, I would check them. In addition, I would have to invent a side channel to inform my subscriber that an error has occurred. As I said, this can be done, but it would be much dirtier.

Answer 6

Consider the following real example. You have a complex recursive function, and you need to exit all current calls in some conditions.

 void complexFunction() { //do stuff, then if( timeToBailOut() ) { // what? how would you get out of all instances at once? } } 

You will need to write those if very carefully, perhaps enter a special return value, always check this value, which will greatly complicate your code. You can easily achieve this behavior with exceptions.

 if( timeToBailOut() ) { throw BailOutException(); } 

Answer 7

There is nothing that could be done with exception handling that cannot be done without it, however in some situations there will be pain without exception handling.

Example: a() calls b() and b() calls to c() . An error can occur in c() , which must be handled in a() . Without exception handling, you will have to deal with it using the sentinel return values ​​in b() and c() , and the extra validation code in b() . You can imagine how much more code you will need to write if the error needs to be transmitted through more levels from what caused it, with what you need to handle it.

This is a short version of my answer to another question that was asked here earlier and rescheduled.