Do I need to use Try/catch throughout a process chain?

Question

Supposing I have a call in my layer controller for a method in the business layer that leads to another method in the data access layer.

Should I use the try/catch in all of them, only in any or depends on?

Below, as an example, I am using everywhere.

Controller:

public ActionResult Index(){
    try{
       var lista = ObterDadosIndicadores();
    }
    catch{
        throw;
    }
}

Business:

    public List<IndicadorProdutoDTO> ObterDadosIndicadores()
    {
        try
        {
            return _dal.ObterDadosIndicadores();
        }
        catch (Exception ex)
        {
            throw new Exception(ex.Message);
        }
    }

DAL:

public List<IndicadorProdutoDTO> ObterDadosIndicadores()
    {
        try
        {
            return lstIndicador;
        }
        catch (Exception ex)
        {
            throw new Exception(ex.Message);
        }
        finally
        {
            FecharConexao();
        }
    }

Answer 1

It depends on the need. That’s one of the things you can’t answer without seeing the actual code, the specific situation. There’s no magic formula, "good practice," or anything like that. You have to have a deep understanding of how the exceptions work to use it correctly in all situations, in a different way according to each need. There has to be a reason for a try-catch. If you do, you can put it everywhere. If you’re going to capture and play forward, that’s no reason, unless you actually have something useful that should be done partially at that point.

In the three examples shown, you should not use the exception capture since you are not doing anything with it. Relaunching it, even more so in the last two examples is unnecessary, and even bad. If you don’t do something useful with the exception do not capture it.

But if you have to capture and do something useful, let that be the most specific exception possible. The capture of Exception should only occur when everything failed. You can only do something useful when you know exactly what the exception was. Exception is too generic for this. Capturing such a generic exception usually only serves to log in the problem and possibly abandon the execution of the application more pleasantly to the user.

But note that log in the error is something: either it has to be a very specific form and there fits the capture, or should leave to a centralized place log in generic form. You should not keep repeating code throughout the application.

The DAL case is very strange. Does it try to close a connection that it did not open? This is not correct. Whoever opened it must close the connection. Then if you do it like this, just use the using to ensure the closure.

You must have seen a lot of code like this. Everything wrong! Does it work? In many cases it works, but working and being right are very different things. What’s wrong, one hour it stops working.

Just to give a parameter, I have applications with only one try-catch. Even large and complex applications don’t often go much further than "half a dozen" of these control structures throughout the code (of course I use a few tricks). Most programmers abuse a resource that does not know its real purpose. In general the person thinks that putting a catch makes the code give fewer errors, when in fact just hide mistakes.

Has languages that require a little more use of exceptions because they use this mechanism as flow control, which is an abuse of the mechanism. Luckily C# does not do so and does not encourage this use. Unfortunately poor quality materials teach abuse.

Have an answer that talks a lot about exceptions.

Other questions on the subject:

• There is some drawback in always catching Exception and not something more specific?
• How to best treat exceptions in Java?
• It is good practice to make an exception in such cases?
• What is the difference between "throw" and "throw ex"?
• Using an empty catch is a bad practice?
• What type of treatment can be performed in this case?
• Where exceptions must be handled to display to the system user?

Some are of different languages, but the information is valid.