Is using an empty catch a bad practice?

Question

Is using an empty catch a bad practice?

Navigation

#1 by (15 votes)

10

There have been cases where I had to make use of methods that throw an exception in case of an error, but the exception would stop the execution of script , which would be something undesirable.

For example, I have a system where, when the student registers the request, an email is sent. The function that sends the email throws the exception. However, since the exception would stop the registration, I preferred to use an empty catch. It was not as important to send the email as the request was registered.

So I did something like this:

try{

    Mail::create('email.aluno')->send($callback);

} catch (\Exception $e) {
    // Se não enviar o e-mail por conta de um erro
    // continue o script
    // Não vamos interromper esse momento tão importante
}

$usuario->fill($dados)->save();

Someone might say: Just take the exception from where it gets thrown. I do not do this, since changing the third party source code is not a good idea, because when I was updating the system, I would have to edit it again, and again and again ...

Is it a bad practice to use an empty% void so nothing happens when the exception occurs?

Would this be an anti-default?

Is there a specific name for this type of operation?

Is there a risk in doing such an operation?

asked by anonymous 12.01.2016 / 16:24

1 answer

Look up values in one data.frame and add in another (R) Copyright and crack

score 15 · Accepted Answer

Yes. Terrible:)

First you would need to see if this really is necessary to throw the exception. I see many cases where the exception is not the most appropriate (see more here and here ).

Maybe it's a vexatious / noisy exception case (see the link there above). Maybe it's a foreign exception, which would be normal.

If everything is normal with the release, then you have to ask yourself why you should not do anything. Is this the expected action? Will not tell, will not logar , will not take a different course, choose an alternative, nothing? Are you going to pretend that nothing happened?

If you have considered all this and are sure that doing nothing is right, then everything is ok. Like everything else, fixed rules are worthless. You have to do what's right in that case.

It's hard to say that there is a case where swallowing the exception doing nothing is right, but it can exist. When this is normal, perhaps the exception is the wrong mechanism. The exception name is not so by chance, it must be something exceptional, not normal.

This case seems strange that can be ignored. "It was not as important to send the e-mail as the request was registered," swears? So do not send it.

It can be called anti-default, but they are there to be used as well. This is called exception swallowing or error hiding . >

You run the risk of doing something wrong: P If it's the right thing to do, it's okay. Make sure that in no time the fact of failure not having a treatment will not cause another problem.

Of course you have a problem in this particular case. You are capturing Exception . This is very wrong, because it will swallow exceptions that need to be addressed, which may even be programming errors (messy). That's serious. If it is to swallow it, it is even more important that it capture a specific good.

What if the thrown exception is not so specific? Find another supplier. This is not good: P