Exceptions vs error codes (exception or error code)

Excpetion is a situation when a piece of code encounters some Unexpected Problem while running, and couldn't accomplish its task. the emphasis on the "unexpected" is important, because it eliminates some scenarios that, from first glance, may require throwing an exception, but I think they really shouldn't do that.

Error, in contrast, is a situation when a piece of code encountersExpectedProblem while running, and couldn't accomplish its task. Again, the emphasis is important. As strange as it may sound, there are expected problems that shocould be taken of while running.

Let's look at a sample:

The read () method of the (SQL | oledb) datareader. this method returns either true or false. false is returned when there are no more rows to read from. if we'll stick only to the "can't accomplish task" definition, then the method shoshould throw something like endofdataexception. but in this case an error code is in order, since this is a (very) expected situation. I mean, you did CT the data Come to its end finally, didn't you?

But-if the connection to the database was terminated suddenly, then this method will throw an exception, since this shoshould not happen, and it is very unexpected (and unwelcome) situation.

If we utilize this definition, we'll find out that the performance penalty of throwing exceptions is insignificant. the application has encountered some unexpected error which it does not know how to handle, and the best thing to do now is write something to log file, close all resources, go to the nearest shelter and pray. performance are really meaningless in this situation.

It's important to avoid using exceptions as flags-"Hey, something happened. now tell us how to go on. "For example, In Ashish disappearing post, the following code sample is written:

========================================================== ==============================

My application, a web-service reads a string column from the database. 50% of the time this string is a datetime, 50% it's not. in. NET 1.0/1.1 It is easy for this to lead to code like the following ..

 Datetime d = datetime. minvalue;

Try

{

D = datetime. parse (string );

}

Catch (invalidcastexcpetion)

{

// Swallow

}

 Put this in a loop in a middle tier Component (say processing A recordset), and load up the server. you'll generate 1000 s of exceptions per second in the Asp.net WP, and can easily drop throughput by an order of magntasks. there are a number of internal and external applications I 've seen coded exactly like this. it's hard to argue with the correctness of the datetime. parse () implementation from a purist POV, but the ramifications can be a lot of money spent on additional hardware by the consumer of the API.

========================================================== ======================================

Couldn't say it better. Again, exceptions shocould be used only when something unexpected happened, and the process (the logical one, not the physical) shocould stop.

There is another reason for not using error codes, and that's the return value type dilemma. when talking about "error code", it's usually a number (eg. -1) or some kind of string. our method won't necessarily return this type. it may return dataset, date, custom objects or anything else. if we wowould like To be able always to return error code, and we'll try to utilize it for every problem, evenUnexpectedOnes, each and every function will have to have "object" as its return type. another alternative is to have another byref argument which will hold the error code, but this will mess up the code and add unnecessary cumbersomeness to the method's interface.

So, to coclude:

When a method has some pre-defined situations when it might won't be able to accomplish its task, it shoshould return an error code.

When a method encounters some unexpected problem which prevents it to accomplish its task, it shocould throw an exception.