The hidden cost of Exceptions in .NET 

I agree that the OneOf conecpt wouldn't be my favorite. Typescript has native support for this by pipe-concatenating type like so: type1 | type2 | undefined .... The point where you need to distinguish between these types then usually becomes messy. But still I wouldn't use exceptions allthe way for expected/common errors.

I don't throw errors in my domain logic. I just return a custom result interface like action methods do.

if 20us makes difference on the application, we probably shouldn't even use C# to build it from the start.

@@Qrzychu92 You catch them in a global exception handler which logs the exception then map it to an appropriate status code and response to the client. It's not hard to add a summary tag on your methods which defines which exceptions it may throw and when it does it.

@@Qrzychu92 I use a pipeline that wraps all requests in a try/catch and logs any exception and throws it. If it's not something expected to be handled within the global handler it's returned as a 500.

A Result object is also a perfect alternative. I’ve been bouncing back and forth between Result and OneOf

Moreover - what if we throwing exceptions wwwaay way deeper? We will have to disfugure all our domain-level code with these clumsy signatures and returns..

Exceptions are only expensive when thrown. At long as exceptions are truly exceptional (i.e. rare) that’s not a problem.

You don't need to handle failed responses explicitly in the OneOf approach. In the same way that you generically handle exceptions when they extend a specific Exception and you map that to a response, you can use the interface in OneOf to map a "Bad action" to a bad response. You can still have the exception handling in there, but for things that are truly "exceptions", not just normal domain behavior masked as something that it isn't

the mistake is thinking that situations such as an empty data field is an exception is where the problem lies. Such errors are not exceptional, they are part of normal error handling (though obviously it depends in practice what data you mean - open a file and read 0 bytes is not an exception, open a file and fail to read because its been deleted from under you, is). Too often exceptions are used for ordinary error conditons that should simply be a null or error code - but throwing is just easier, then its someone else's problem. And quite possibly major performance issue.

The contract is on the API level not the domain. The domain can change but the contract stays the same. Remember you only have one "Good" response in OneOf, the first one, which represents your core contract for that endpoint. All the others are the potential "bad responses" that will get mapped to the "ErrorResponse" contract, which will be static.

I have a video on the WebApplicationFactory on the integration tests video. In terms of returning I was using Result at the time which return the good object or an exception and then I was handling the exception based on the type, but it was returned not thrown. The reason why I moved away was because it does t feel appropriate to use an exception to represent a bad state in the domain.

By your explanation, the exception approach also violates the O in SOLID because somewhere something has to be modified. Open/closed doesn't mean that you should never edit your code. If your method needs to also handle something new, but still falls under the concerns of that single method, hanse the return type change, then there is nothing wrong with that. Requirements change. The point of O is that if you need to add something new in your system you should be able to do that without mofifying existing code. Your requirement doesn't fall under that.

@@ericnewton5720 yeah, sometimes, it all depends on the project really

Agreed. This isn’t about database lever concerns but rather domain level. A database isn’t really a concept of the domain but domain validation is

You can handle with monad (OneOf is a good example) to not tie results with libraries!

It's not one or the other. Some people opt in to use a Result object instead of OneOf that returns either a "good" object or an exception but it returns it, it doesn't throw it. The OneOf approach is definately harder to manage in a monolith application, in which case the Result version is better. In microservices I have found that OneOf is perfectly managable but this ofc depends on the complexity of your domain.

@@nickchapsas It's true that it's not one or the other. But if you don't commit to one or the other, you will end of with a Frankenstein solution in my opinion.

@@buriedstpatrick2294 Yeah sorry I mean, not one or the other in the grand scheme of things. In a single solution you should pick one and use that one consistently whatever it is.

This isn't about optimizing anything. It is about using a language feature properly and better designing your application's code.

You kinda did make it about optimizing, showing several tests highlighting the cost in execution time when using error codes vs exceptions vs OneOf, and even naming the video "hidden cost". But in the end, the cost differences were so slight, that yeah this isn't really about optimizing anymore and becomes more about how cleanly can you manage "exceptional" or error states in your code/service.

@@williamfleetwood4612 slight cost differences can become big ones in certain circumstances. I still learned something from this video.

@@AlbertoMonteiro I think exceptions are not really named well. In my opinion, it's not about exceptional events, rather it shows that the method is not behaving as expected.

@@AlbertoMonteiro Usually, I create all sort of custom exceptions to meaningfully show what is failing and why. At the end, all it matters is to be consistent across your code base to make the code behaving in the expected way. All these topics are highly opinionated and subjective, and the diversity in opinions what makes it beautiful.

I can recommend CSharpFunctionalExtensions

Yeah I find the Tuple approach faulty because it requires extra logic to properly handle the response. Also tuples don't force you to handle every possible scenario. OneOf does. It's way safer IMO.

Doing the same. The frontend itself should check the inputs and give the user a response. If my API checks it and the input is wrong it doesn't have to be catched and shown to the user. A possible log entry is more than enough xD

A lot of the old business apps i work on use that same pattern, I think it's ok but does require you to have an errorMsg variable floating around whenever you need to call something

It's not exceptions in general but rather the throwing part of exceptions. It just interrupts the flow in a way that is costly for the flow. I haven't dived into the JIT to investigate exactly why.

​@@nickchapsas Yeah, that's what I figured. You'd expect a similar/higher cost on every virtual method call if it were just a CPU thing though

I prefer to have my swagger responses driven by “Produces” attributes and not leave it up to chance to see what it can figure out.

I don't delete any comments. If you linked something then the spam filter might have caught it. This is NOT returning error codes. This is the exact same behavior as exceptions, but you are no longer actually throwing exceptions and you are using a domain object to represent the validation error instead. Both the Exception and the validation object will be mapped to a BadRequest. It's the same behavior just faster, and in my opinion, cleaner.

@@nickchapsas It's not the same behaviour as exceptions, because it doesn't interrupt code flow, and the calling code is able to ignore the return value. Code written after the invocation of the method cannot assume that the data is in an acceptable state to continue without a manual check of the return value.

@@jez9999 But you will need at some point in your request pipeline to do a manual check to see if an exception is of a specific type. You don't just randomly convert any exception to a 400 error. You check for specific types and you map the appropriately. If you do map any exception blindly then that's even worse.

All the benchmarks are in release mode. Benchmarks cannot run in debug mode.

There are many ways to skin a cat. Domain validation wouldn't happen higher than the service that the controller calls. Now whether that "service" is a mediator and validation is part of the pipeline pre-execution, or whether you explicitly call a validator's validate method that's a different story, but even then the validation logic should not throw IMO. It should return an object of some sort capturing the error and then bubble it up appropriately all the way to the controller.

Yeah it's trying to replicate Discriminated Union behavior

You kinda don’t, at least not with the core design. Those clean code architecture templates are linked to the idea that an exception can be thrown from anywhere, especially the domain from value objects. Unless you re architect it a bit, you are stuck

This isn't about return codes but rather responses. Also define "Goes wrong". Does a user trying to sign in with an existing email fall under "goes wrong"? I would say no. It's just normal domain behavior which can be represented with a domain object, not with an arbitrary exception. You should still have a "catch-all" middleware for actual exceptions that is from stuff you don't expect or can't control but I wouldn't use them to map into responses.

I agree with Nick. Notice his clear distinction about early validation and being able to return these validation errors. Whether you return them as OneOf, plain string messages, ValidationResults, etc., anything is better than using exceptions for general code flow. The underlying message is: do not throw exceptions for simple validation or code flow. If you own both the frontend and backend then doing more or even all validation in the front end is desired. Don't make your front end make unnecessary calls to your back end that you know will fail. now if you are only writing a backend api, something you are selling or does not have a single frontend, so therefore many outside clients are using.. you have no choice then to put validation into your backend api. Don't let your api code go way down a call stack and let it fail with an exception if you could have caught it with simple validation. the advice from clean code is definitely true and should also be used. If you would have done your pre-emptive validation and all data seems fine and then only deeper in your method call stack something seems to "go wrong" unexpectedly, for example retrieving a file by passed in file name and you check whether the file exists, then if it doesn't then just use exceptions. Do not try to get tempted into writing code where every method returns some arbitrary integer codes meaning things. Place yourself in the user perspective; if you would be consuming an api and your result code is 0 for the last weeks or months and all of a sudden you'll get a vague 0x00040592 code, that's terrible! I'll hope that you would favour an exception with a descriptive message and possible other data hinting to what is the problem. The clean code advice is also more geared to usage within the language itself, api's on code level, like a dll/package that you are using. WebApi's in that sense have an extra challenge, especially when consumed by different frontend technologies.

It performs the same on the happy path for both approaches. Your code isn't slower for using exceptions. Only throwing them is.

@@ericnewton5720 Where is it written you shouldn't? Exception means something abnormal has just happened and you won't be able to handle the user's request. Hence it makes total sense to throw an exception.

2 reasons. First tuples need all typle values returned to have the tuple itself returned. If you are forced to return some value or null for the other objects then that's really bad. Also tuples don't force the consumer to handle every possible tuple value. Discriminated unions do.

Because enums don't contain the object's data that you might need. Switches don't force you to handle every case. OneOf does.

@@nickchapsas after viewing it a second time I really like it. I think I'll give it a crack.

True, but should bad requests be considered "exceptional"? I don't think so. Throwing an exception is synonymous with _crashing_ to me, and I don't like my applications to crash because of something like bad input. Anyway, unless you barely have anything to validate, you'd usually use something like FluentValidation to handle this, which does not push you toward relying on exceptions.

Yeah Result is a perfect alternative. OneOf can also be encapsulated in its own class to hide the length

Without any errors the performance is the same for both speed an allocations. ExceptionVersion | 89.95 us OneOfVersion | 89.97 us You can calculate the offset in performance difference since it will be almost linear since the cost of the exception is pretty much static.

@@nickchapsas you are saying that returning some string in case of using exceptions when no error is same speed as using OneOf construct? how come then the first test without use of any exceptions was so much faster, not just some 20% faster?

​@@lordicemaniac Because the first test was only focusing on the Exception case. The last tests look at the problem form an external end-to-end perspective and a lot of those concerns are getting load leveled by other stuff that happened in the flow

@@nickchapsas i see... btw i love your videos, keep them coming :)