Question: Performance overhead of throwing exception for validation Errors?

[maulik-modi]

@jasontaylordev ,
What is the performance overhead of throwing ValidationException as opposed to returning errors?

According to https://enterprisecraftsmanship.com/, we should avoid throwing exceptions and return Error objects?

[cantti]

Hi, I think that there is an overhead, but it is not so big. In the classic asp net, the practice of throwing exceptions was common (HttpResponseException).

But I'm also interested in the topic of validation. It is not always convenient and correct to describe all the rules in Fluent Validation. What is the best way to return validation errors from the command? Throwing exceptions is not the best practice (aspnet/Mvc#4311 (comment)). Vladimir Khorikov tells it too.

[maulik-modi]

@cantti , there are two types of validations:

1. Model Validations
2. Command Validation Business Rules

[cantti]

@maulik-modi
Yes. And how to work with the second type of validation? Where to write this rules?

[maulik-modi]

@cantti , Check CreateCustomer method here https://enterprisecraftsmanship.com/posts/functional-c-handling-failures-input-errors/

[cantti]

@maulik-modi
Thanks, I think it is a good solution, to return result from commands. I'm used to using a different pattern https://enterprisecraftsmanship.com/posts/validation-and-ddd/ (5th solution). But Result is also fine.

[vlmironoff]

With the modern server cpus and amounts of ram you can safely afford using exceptions instead of error pocos. The simplicity of your project will pay more.

[maulik-modi]

Classic answer to all cross cutting concerns is "IT DEPENDS", hence I would like to know the breaking point. If bottomline is performance, simplicity may not get buy in

[maulik-modi]

@vlmironoff , Is there any possibility of crashing by firing 100 requests that causes validation error?