Let's say I have my layers
So it is necessary to create this block in the 3 layers or create only in controller ?
If I do this does it guarantee that any code that is made inside it will be thrown at it? Do you ever run the risk of losing stack trace ?
First, it depends on what you are calling the layer. If they are code layers within the same application, yes, the exception will bubble until someone else catches it, in the latter case .NET captures you and does something (shows the error by default).
Exception is a complicated mechanism, it is a goto that you do not know or where it will stop. You do not have to deal with failure (contrary to what many people say about this mechanism) and do not know who will deal with it.
If you do it right, do not lose the stack trace , but for this it is important not to get caught to throw the exception again. The problem is that in exception-abusing code and using it as a validation mechanism it is common to do this, especially in layers, so its tendency will be to capture in one layer to throw something else on another layer.
Often throwing exceptions can be abstraction leak. It is very complicated to make the exception be natural, one of the reasons not to use it for flow control, as it seems to be the case you are trying to do, because even if they were used for exceptional situations you probably would not be living this dilemma. / p>
Without a thorough analysis it is difficult to give a definitive answer on the problem, and even more generic solutions cause controversy, I have seen people defending one thing or another.
If you use it right the exception should not go beyond the layer where it originates, another reason not to worry about stack trace . In the repository it seems like a suitable place to capture some very specific exception types.
In the business layer you should rarely have exceptions because there you will only have validations, you will only have things that you have control of, which fails is probably expected, not exceptional.
But it's always possible to do something different. If it is the controller that assembles what will be shown to the user, there may be the appropriate location to capture a true exception. There are controversies about this, but one of the advantages of the exception is not having to go over, you let it pop until you get to the place where you can do something useful, and most of the time it's going to interact with the user (though controller is not the interaction location, it is the last code that will run on this solution layer, the backend side).
1- I prefer to handle errors in a higher controller type layer.
2- You will not miss the stacktrace on the first error that the catch catch catch it will try and throw the exception.
3-When to use? you should use try catch in parts of the application that you know that errors can occur, say by external influences like access to a database, manipulation of files, etc.
