DEV Community

Result Pattern

Ben Witt on June 11, 2024

The use of exceptions in C# is basically okay, but you should be careful not to use too many exceptions. If exceptions are constantly used for all...
Collapse
 
chiroro_jr profile image
Dennis

I understand it's an example but I am not sure why the code below needs to be an exception

if (denominator == 1)
  {
    throw new Exception("Division by 1 always results in the dividend.");
  }
Enter fullscreen mode Exit fullscreen mode
Collapse
 
ben-witt profile image
Ben Witt

Hey!
We hereby create our own error object which we want to manage ourselves. We do not use the exception handling of dotnet here, as this can be very "expensive". This is about known errors that can occur. It is not about unexpected errors

Collapse
 
cmessoftware profile image
CMES Software

Hi, I use the Ardalis.Result package and result succesful for web apis.

Collapse
 
juliomoreyra profile image
JulioMoreyra

Hi! There's a nugget package called ErrorOr that's implementing this pattern. Search it at GitHub

Collapse
 
hng_u_6d0e3174aef04cb7 profile image
Hùng Đậu
  1. We lose the call stack if no exception is thrown. Terrible if we are trying to debug. Add call stack to the Error object should fix issue
  2. Doesn't address complicated nested exception flow although I guess we could modify to have nested Error map instead of just 1 Error object.

Overall a neat idea for Error flow design. Leave the try catch block for unexpected exception scenario.

Hope there is also a design pattern to convince your fellow engineers to use this pattern instead of throwing try catch exception everywhere then use finally block as flow control to further throw more exceptions.....

Collapse
 
ben-witt profile image
Ben Witt

I just have one question, if you have your own error object and you know exactly where the error occurs, why do you need the call stack? It needs a lot of power which is not needed here!

Collapse
 
hng_u_6d0e3174aef04cb7 profile image
Hùng Đậu

Hi Ben,

Thanks for the question, its for debugging reusable workflow.

Let's say we are executing : A -> B -> C -> D and another A -> Z -> L -> D. If error happened at D and we are evaluating the error at A, I would like to know the exact path it went through instead of just result code and message.

Thread Thread
 
ben-witt profile image
Ben Witt

Makes no sense, as you know exactly which one occurred, even where it occurred. You don't need the stack, in this case it's pure overhead!

Thread Thread
 
hng_u_6d0e3174aef04cb7 profile image
Hùng Đậu

Yeah on second thought, you probably don't need the exception stack if the error classes and error flows were well defined.

The code I was working doesnt have well defined exceptions and rethrow a different generic Exception everytime it entered catch block. It's hard to traceback to the original location so maybe unconsciously I thought of using a combined stacktrace to tackle this issue. 🤔 Does this make better sense?

Thread Thread
 
ben-witt profile image
Ben Witt

This example is about implementing an error structure, as error handling under .Net is good but unfortunately very resource-intensive.
If your project relies on the .Net standard, this is not wrong, but it can cost performance.
If you get error messages that come from code where you don't know where it occurs, the stack is essential.

Collapse
 
selmaohneh profile image
Marcel Neumann

I made a post that explains the advantages of the result pattern on a simple real-life example. Maybe check it out:

dev.to/selmaohneh/how-and-where-to...