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

Question

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

Navigation

#1 by (9 votes)

8

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

Should I use try/catch in all of them, just in some or depends?

Below, as an example, I'm using it 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();
        }
    }

c# asp.net-mvc try-catch

asked by anonymous 16.05.2016 / 17:06

1 answer

Static Blocks, Inheritance, and Constructors in Java How to compile the database to install together with a C # application?

score 9 · Accepted Answer

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

In the three examples shown, you should not use catching the exception since you are not doing anything with it. Re-launching it, even more of the last two examples is unnecessary, and even bad. If you're not going to do anything useful with the exception, do not capture it.

But if you have to capture and do something useful, make it the most specific exception possible. Capturing Exception should only occur when everything has failed. You can only do something useful when you know exactly what the exception was. Exception is too generic for this. The catch of this generic exception usually only serves to logar the problem and possibly abandon the execution of the application in a more pleasant way to the user.

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

The case of the DAL is quite weird. Does he try to close a connection that he did not open? This is not correct. Who opened should close the connection. Then, if you do, just use using to ensure closing.

You must have seen a lot of code like this. All wrong! It works? In many cases it works. But working and being right are very different things. What's wrong, one hour does not work.

Just to give a parameter, I have applications with only a try-catch . Even large and complex applications do not usually spend a lot of "half a dozen" of these control structures, all over the code (of course I use a few tricks). Most programmers abuse a feature that is unaware of its real purpose. In general the person thinks that putting a catch makes the code give less errors, when in fact they only hide errors.

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

I have a response that talks a lot about exceptions .