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

Anyway, you usually just want to give a handle to the exception. try catch is not a normal flow control , so it rarely makes sense to have them nested. The throwing of an exception is a long jump , that is, it goes to a distant, possibly unknown location. So it does not matter so much where catch is, it can, and is very common, not even in the current function. This is normal.

The important thing when an exception is thrown is that it is caught 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. Do not worry about the flow, it will already be "distorted" from your normal after throw .

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

Then 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 placed it on GitHub for future reference.

If there is a problem with PDOExcption when calling Bd() or createCreateEntidade it will deflect to the first catch . If ExceptionSeiLa occurs, probably generated by the geraPdf method, the deviation will be for the second catch .

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

Of course there may be any situation where nesting is useful. But it's extra rare.

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

But avoid abusing catching exceptions that you can not do anything useful. I understand you just made a simple example, but if you catch an exception and do nothing with it, something is wrong.

Personally if I can avoid using the exception, I do. If I can check with if if there is something wrong, I will. I only use exception if:

• the algorithm with if gets more confusing than with try catch
• can generate a race condition or considerable loss of performance
• The API forces you to do this (there is no other way to "catch" the error).

This last case is very common in Java. The language culture and environment encourage the use of exceptions.

I do not have much experience with new PHP APIs, but what I've always used in PHP, exceptions are rarely necessary. There is always a way to resolve the issue without its use. But PHP started without exceptions if it did very well without them. Of course its addition brought new perspectives but also brought a lot of abuse.

You can still fall into the first two cases. In the former it may be more advantageous to prefer the exception and in the latter it may be required to have the correct solution and adequate performance.