Using a try-finally (without catch) vs enum-state validation

Question

I have been reading the advice on this question about how an exception should be dealt with as close to where it is raised as possible.

My dilemma on the best practice is whether one should use a try/catch/finally to return an enum (or an int that represents a value, 0 for error, 1 for ok, 2 for warning etc, depending on the case) so that an answer is always in order, or should one let the exception go through so that the calling part would deal with it?

From what I can gather, this might be different depending on the case, so the original advice seems odd.

For example, on a web service, you would always want to return a state of course, so any exception has to be dealt with on the spot, but lets say inside a function that posts/gets some data via http, you would want the exception (for example in case of 404) to just pass through to the one that fired it. If you don't, you would have to create some way to inform the calling part of the quality of the outcome (error:404), as well as the outcome itself.

Though it IS possible to try-catch the 404 exception inside the helper function that gets/posts the data, should you? Is it only I that use a smallint to denote states in the program (and document them appropriately of course), and then use this info for sanity validation purposes (everything ok/error handling) outside?

Update: I was expecting a fatal/non-fatal exception for the main classification, but I didn't want to include this so as not to prejudice the answers. Let me clarify what the question is about: Handling the exceptions thrown, not throwing exceptions. What the desired effect is: Detect an error, and try to recover from it. If recovery isn't possible, provide the most meaningful feedback.

Again, with the http get/post example, the question is, should you provide a new object that describes what happened to the original caller? If this helper was in a library you are using would you expect it to provide you with a status code for the operation, or would you include it in a try-catch block? If you are designing it, would you provide a status code or throw an exception and let the upper level translate it to a status code/message instead?

Synopsis: How do you chose if a piece of code instead of producing an exception, returns a status code along with any results it may yield?

Answer 1

Exceptions should be used for exceptional conditions. Throwing an exception is basically making the statement, "I can't handle this condition here; can someone higher up on the call stack catch this for me and handle it?"

Returning a value can be preferable, if it is clear that the caller will take that value and do something meaningful with it. This is especially true if throwing an exception has performance implications, i.e. it may occur in a tight loop. Throwing an exception takes much longer than returning a value (by at least two orders of magnitude).

Exceptions should never be used to implement program logic. In other words, don't throw an exception to get something done; throw an exception to state that it couldn't be done.

Answer 2

Some good advice I once read was, throw exceptions when you cannot progress given the state of the data you are dealing with, however if you have a method which may throw an exception, also provide where possible a method to assert whether the data is actually valid before the method is called.

For example, System.IO.File.OpenRead() will throw a FileNotFoundException if the file supplied does not exist, however it also provides a .Exists() method which returns a boolean value indicating whether the file is present which you should call before calling OpenRead() to avoid any unexpected exceptions.

To answer the "when should I deal with an exception" part of the question, I would say wherever you can actually do something about it. If your method cannot deal with an exception thrown by a method it calls, don't catch it. Let it raise higher up the call chain to something that can deal with it. In some cases, this may just be a logger listening to Application.UnhandledException.

Answer 3

use a try/catch/finally to return an enum (or an int that represents a value, 0 for error, 1 for ok, 2 for warning etc, depending on the case) so that an answer is always in order,

That's a terrible design. Don't "mask" an exception by translating to a numeric code. Leave it as a proper, unambiguous exception.

or should one let the exception go through so that the calling part would deal with it?

That's what exceptions are for.

dealt with as close to where it is raised as possible

Is not a universal truth at all. It's a good idea some times. Other times it's not as helpful.

Answer 4

I agree with S.Lott. Catching the exception as close as possible to the source may be a good idea or a bad idea depending on the situation. The key to handling exceptions is to only catch them when you can do something about it. Catching them and returning a numeric value to the calling function is generally a bad design. You just want to let them float up until you can recover.

I always consider exception handling to be a step away from my application logic. I ask myself, If this exception is thrown how far back up the call stack do I have to crawl before my application is in a recoverable state? In a lot of cases, if there isn't anything I can do within the application to recover, that might mean I don't catch it until the top level and just log the exception, fail the job and try to shut down cleanly.

There is really no hard and fast rule to when and how to set up exception handling other than leave them alone until you know what to do with them.

Answer 5

Exceptions are beautiful things. They allow you to produce a clear description of a run time problem without resorting to unnecessary ambiguity. Exceptions can be typed, sub-typed, and may be handled by type. They can be passed around for handling elsewhere, and if they cannot be handled they can be re-raised to be dealt with at a higher layer in your application. They will also automatically return from your method without needing to invoke lots of crazy logic to deal with obfuscated error codes.

You should throw an exception immediately after encountering invalid data in your code. You should wrap calls to other methods in a try..catch..finally to handle any exceptions that might be thrown, and if you don't know how to respond to any given exception, you throw it again to indicate to higher layers that there is something wrong that should be handled elsewhere.

Managing error codes can be very difficult. You usually end up with lots of unnecessary duplication in your code, and/or lots of messy logic to deal with error states. Being a user and encountering an error code is even worse, as the code itself won't be meanful, and won't provide the user with a context for the error. An exception on the other hand can tell the user something useful, like "You forgot to enter a value", or "you entered an invalid value, here is the valid range you may use...", or "I don't know what happened, contact tech support and tell them that I just crashed, and give them the following stack trace...".

So my question to the OP is why on Earth would you NOT want to use exceptions over returning error codes?

Answer 6

All good answers. I would also like to add that returning an error code instead of throwing an exception can make the caller's code more complicated. Say method A calls method B calls method C and C encounters an error. If C returns an error code, now B needs to have logic to determine if it can handle that error code. If it can't then it need to return it to A. If A can't handle the error then what do you do? Throw an exception? In this example, the code is much cleaner if C simply throws an exception, B doesn't catch the exception so it automatically aborts without any extra code needed to do so and A can catch certain types of exceptions while letting others continue up the call stack.

This brings to mind a good rule to code by:

Lines of code are like golden bullets. You want to use as few as possible to get the job done.

Answer 7

I used a combination of both solutions: for each validation function, I pass a record that I fill with the validation status (an error code). At the end of the function, if a validation error exists, I throw an exception, this way I do not throw an exception for each field, but only once.

I also took advantage that throwing an exception will stop execution because I do not want the execution to continue when data is invalid.

For example

procedure Validate(var R:TValidationRecord);
begin
  if Field1 is not valid then
  begin
    R.Field1ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end; 
  if Field2 is not valid then
  begin
    R.Field2ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end;
  if Field3 is not valid then
  begin
    R.Field3ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end;

  if ErrorFlag then
    ThrowException
end;

If relying on boolean only, the developer using my function should take this into account writing:

if not Validate() then
  DoNotContinue();

but he may forgot and only call Validate() (I know that he should not, but maybe he might).

So, in the code above I gained the two advantages:

1. Only one exception in the validation function.
2. Exception, even uncaught, will stop the execution, and appear at test time

Answer 8

There isn't one answer here -- kind of like there isn't one sort of HttpException.

It makes alot of sense that the underlying HTTP libraries throw an exception when they get a 4xx or 5xx response; last time I looked at the HTTP specifications those were errors.

As for throwing that exception -- or wrapping it and rethrowing -- I think that really is a question of use case. For example, if you are writing a wrapper to grab some data from the API and expose it to applications you could decide that semantically a request for a non-existent resource that returns a HTTP 404 would make more sense to catch that and return null. On the other hand a 406 error (not acceptable) might be worth throwing an error as that means something has changed and the app should be crashing and burning and screaming for help.