How to use a Try catch inside another?

Question

I need to write data into a database, and if it succeeds, then I will generate a .pdf with PHP.

Even if I put one try catch in a part of the code and it gives the exception, still the rest of the code will run. It would be bad if I put a try catch within another? If not, what would be a valid option without killing any good practice? Use one if to check whether $bancoDeDados is not empty?

My Code

try {
    $bancoDeDados = new Bd();
    $bancoDeDados->createCreateEntidade($valor1,$valor2);
    try {
        $this->geraPdf($valor1,$valor2);
    }
    catch(ExceptionSeiLa $e) {
    }
}
catch (PDOException $e) {
}

What I need

I need this PDF generation to occur only if Insert is successful.

Answer 1

Each case is a case, but in general nesting of try is not the most appropriate. This probably indicates that you are capturing more exceptions than you should.

Anyway, usually you just want to give a treatment for the exception. try catch is not a normal flow control, so it rarely makes sense to have them nestled. The launch of an exception is a long jump, that is, it goes to a distant place, possibly unknown. So it doesn’t matter so much where the catch, it may, and is very common, not even in the current function. This is the normal.

The important thing when an exception is thrown is that it is captured by some catch somewhere in your application code, anywhere it is appropriate to capture and do something useful to try to recover from the error. Don’t worry about the flow, it will already be "distorted" from its normal after the throw.

This capture can be unique throughout the system, just to log in the error and present in a "beautiful" way to the user. Do not abuse error capture. See more about this in other answers from me. It is important to note that using a catch does not work miracles, it does not solve problems by itself. On the contrary, its exaggeration makes hide mistakes.

So in your example the "most correct" would be:

try {
    $bancoDeDados = new Bd();
    $bancoDeDados->createCreateEntidade($valor1,$valor2);
    $this->geraPdf($valor1,$valor2);
}
catch (PDOException $e) {
    //faz alguma coisa
}
catch(ExceptionSeiLa $e) {
    //faz alguma coisa
}

I put in the Github for future reference.

If there’s a problem PDOExcption when you call the Bd() or the createCreateEntidade He’ll divert to the first catch. If it occurs to ExceptionSeiLa, probably generated by the method geraPdf, the deviation will be for the second catch.

A catch does not need and, in general, should not be associated with a try exclusive. You should treat all the exceptions you need to treat at this time in a row, and not once in a nested way.

Of course can there is some situation that nesting is useful. But it is extremely rare.

If an exception is generated before executing the geraPdf(), probably by Bd() or the createCreateEntidade, certainly it will not run, the exception generates a detour before reaching it and does what you want. Depending on what you want, maybe even the second catch is unnecessary.

But avoid abusing the catch of exceptions that you can’t do anything useful. I understand you did just one simple example, but if you capture an exception and do nothing with it, something is wrong.

Personally if I can avoid using exception, I do it. If I can check with if if there’s something wrong, I do it. I only use exception if:

• the algorithm with if be more confused than with the try catch
• can generate a race condition or considerable loss of performance
• the API requires doing this (there is no other available way to "catch" the error).

This latter case is very common in Java. Language culture and environment encourage the use of exceptions.

I don’t have much experience with new PHP Apis, but what I’ve always used from PHP, exceptions are rarely necessary. There is always a way to solve the issue without its use. But PHP started with no exceptions and got along very well without them. Of course its addition brought new perspectives but also brought much abuse.

You can still fall in the first two cases. In the first it may be more advantageous to prefer the exception and in the second it may be mandatory to have the correct solution and with adequate performance.