CODEWITHSUNDEEP
c#exceptionerror-handling
Alecu
Alecu

Reputation: 2708

C# Exception handling versus return error from method result

I am developing some c# classes or better said components. They are nested quite deep one within another and anything can go wrong at any step.

So I can have class A that calls a method on class B that can call methods on classes C and D. Now something can go wrong in any of these classes, except for class A which is responsible for handling any errors that happen during processing to alert the user and generate a proper response for the processing.

Now the problem is that I do not know which approach to use. I can use exceptions and catch them in the top level class A or return individual results from each method that is called on nested classes that contain information if the process was successful or not. This would be the most convenient because all I need is to catch exception on the top level class. On the other hand this might be slow. This can happen like 100 times each minute and even 10 times per second.

So using the approach above my class A would look like:

public class A
{
     private ILog _logger = ObjectFactory.GetInstance<ILog>();

     public void ProcessMethod()
     {
          try
          {
              var b = new B();
              b.Process();
          }
          catch(ProcessException ex)
          {
              _logger.Debug(ex.Error);
          }
     }
}

Or I can use to return from the method if the execution was successful. I am trying to avoid this because it is more work and harder to maintain:

public class A
{
     private ILog _logger = ObjectFactory.GetInstance<ILog>();

     public void ProcessMethod()
     {

          var b = new B();
          var result = b.Process();
          if (result.HasError)
          {
               _logger.Debug(result.Error);
          }
     }
}

Upvotes: 2

Views: 1958

Answers (1)

jcharlesworthuk
jcharlesworthuk

Reputation: 1079

I think it depends on what the exceptions are. I don't like the second approach because, as you said, it is more code and more to maintain and there is always the risk that would will forget to check the "HasError" flag and that will cause you no end of headaches when you don't know why something didn't work.

So I would generally go with throwing exceptions however - you need to think about what exactly it is that will cause something to go wrong.

Is it the user inputting invalid data? If so then you should probably do some validation before calling the method.

Is it an external resource like a database or file system that could throw an error? If so then you should probably allow it to propagate through and catch it in your class A.

Basically, if you can try to eliminate any situations where you would have an error, then if all else fails it's perfectly fine to throw an exception and let it "ripple up" to the top-level class. You could (and probably should) create some custom exception classes for these too so you can have different catches. for example:

public void ProcessMethod()
     {
          try
          {
              var b = new B();
              b.Process();
          }
          catch(DatabaseException ex)
          {
              _logger.Debug(ex.Error);
          }
          catch(InvalidInputException ex)
          {
              _logger.Debug(ex.Error);
          }
          catch(ProcessException ex)
          {
              _logger.Debug(ex.Error);
          }
     }

Also - on an entirely seperate note, have you considered injecting your _logger instance into class A instead of calling ObjectFactory.GetInstance<ILog>();

Upvotes: 2

Related Questions