Error communication and recovery approaches in .NET

Question

I am trying to do error communication and recovery in my C# code without using Exceptions. To give an example, suppose there is a Func A, which can be called by Func B or Fu

Answer 1

I use the FunctionResult approach extensively in ms-access and it works wonderfully. I consider it far better than error handling. For a start, each error message is application specific and is not the usually off target default error message. If the error propagates up a call list of functions, the error messages can be daisy chained together. This eventual error message looks like a call stack but is cleaner e.g. [Could not read photos from Drive F:, Could not read files, Drive not ready]. Wacko, I have just discovered that some Drives can be mounted but not ready. I could not have unit tested for that error as I didn't know that such an error could occur (means SD card reader is empty). Yet even without prior knowledge of this error, I could write an application that handled it gracefully.

My method is to call a method in a class that is written as a function that returns a boolean value. The return value is set to True in the last line of the function so if the function is exited before the last line, it is by default unsuccessful. I code, calling the function looks like if getphotos(folderID) then...do something .. Else report error. Inside the class module is a module level error variable (Str mEM) and it is read via a getter, so the class has an .em property which holds the error message. I also have a comment variable which is sometimes used like an error message, for example if the folder is empty, the code that looked for photos worked but did not return any photos. That would not be an error but it is something that I might want to communicate to the calling program. If there was an error, the user would get an error message and the calling procedure would exit. In contrast, if there was a cmt, such as 'no photos', then I might skill trying to read the photo metadata for example. How does Zdeslav Vojkovic handle subtlies like that with exceptions?

I am moving to C# hence finding this thread. I like the certainty of knowing why function calls failed (I interact with databases and filing systems all the time so I struggle to cover my projects with Unit Tests). I do agree with Zdeslav Vojkovic about using exceptions where their used is standard, but will not be be doing so in my own code. I am looking for a clean design pattern that allows me to validate parameters within the called function and to inform the caller if the parameters were not right.

Answer 2

How about a common FunctionResult object that you use as an out param on all your methods that you don't want to throw exceptions in?

public class FuncResultInfo
    {
        public bool ExecutionSuccess { get; set; }
        public string ErrorCode { get; set; }
        public ErrorEnum Error { get; set; }
        public string CustomErrorMessage { get; set; }

        public FuncResultInfo()
        {
            this.ExecutionSuccess = true;
        }

        public enum ErrorEnum
        {
            ErrorFoo,
            ErrorBar,
        }
    }

    public static class Factory
    {
        public static int GetNewestItemId(out FuncResultInfo funcResInfo)
        {
            var i = 0;
            funcResInfo = new FuncResultInfo();

            if (true) // whatever you are doing to decide if the function fails
            {
                funcResInfo.Error = FuncResultInfo.ErrorEnum.ErrorFoo;
                funcResInfo.ErrorCode = "234";
                funcResInfo.CustomErrorMessage = "Er mah gawds, it done blewed up!";
            }
            else
            {
                i = 5; // whatever.
            }

            return i;
        }
    }

Make sure all of your functions that can fail without exceptions have that out param for FuncResultInfo

Answer 3

"is it the way professional libraries are written?"

No, professional libraries are written by using exceptions for error handling - I am not sure if there is a pattern for using your suggested approach, but I consider it an anti-pattern (in .NET). After all, .NET itself is a professional framework and it uses exceptions. Besides, .NET developers are used to exceptions. Do you think that your library is really that special to force the users to learn completely different way of error handling?

What you just did is reinvent the COM error handling. If that is what you want to do then check this and ISupportErrorInfo interface for some ideas.

Why do you want to do this? I bet it is a performance 'optimization'.

Fear of performance issues with regard to exception handling is almost always a premature optimization. You will create an awkward API where each return value must be handled via ref/out parameters and which will hurt every user of your lib, just to solve the problem which likely doesn't exist at all.

"Func A may not know whether the caller function will have the intelligence to recover from the error or not, so I do not want to throw exceptions"

So you want to ensure that caller silently allows FuncA to mess up the system invariants and caller just goes on happily? It will just make it much harder to debug seemingly impossible bug which happens in another function later on due to this.

There are scenarios where it makes sense to avoid exceptions, but there should be a good justification for that. Exceptions are good idea.

EDIT: I see that you have added that you "have read many other articles also, which suggest not to use exceptions for code flow control". That is correct, exceptions in .NET are not for code flow but for error handling.

You ask:

If Func A calls Func B,C,D,E,F and it has to encapsulate each call with try catch because it can recover from error or it will still like to execute remaining function calls, then is not so many try catch statements awkward

not more than alternative. You are making a mistake that you can simple handle all errors returned from functions in a same way but you usually can't.

Consider if you need to handle every function separately - worst case scenario and code is usually not written like that:

Result x, y;
try {
   x = Function1();
}
catch(SomeException e) {
   // handle error   
}
try {
   y = Function2();
}
catch(SomeOtherException e) {
   // handle error   
}

against:

int error;
Result x, y;
error = Function1(out x);
if(error != SOME_KNOWN_ISSUE) {
   // handle error    
}
error = Function2(out y);
if(error != SOME_KNOWN_ISSUE) {
   // handle error
}

not a big difference. please don't tell me that you would not check the error code. However, if you decide to ignore all errors (a horrible idea) then exceptions are simpler:

try {
    var x = Function1();
    var y = Function2();    
    var z = Function3();
}
catch Exception() { you still can see the message here and possibly rethrow }

vs

Result1 r1;
Function1(out r1);
Result2 r2;
Function2(out r2);
Result3 r3;
Function3(out r3);
// and here you still don't know whether there was an error

Can you elaborate what do you mean by "I need predictability with regard to time constraints"?

in some system level software or realtime stuff, you can't afford stack unwinding related to exception handling, as you can't guarantee the duration, and that could violate your timing requirements. But this is never the case in .NET as garbage collection is far worse in this regard.

Also, when you say "In .NET I would always use the exceptions for error handling", can you explain how or what do you define as an error condition? Is a recoverable situation an error condition or not an error condition? –

@shambulater already gave a great example in comments. In FileStream, missing file is not recoverable and it will throw. In the client of FileStream it might be recoverable or not depending on context. Some clients will ignore it, some will exit the app, some will wrap it in another exception and let someone upstream to decide.

When will you not use exceptions?

In those cases where I would also not return an error code.