Try with empty Catches

Question

Say I have a try statement with and empty catch is that bad practice? For example say I have 2 try separate trys where it is possible for one to fail but the other to succeed or both succeed or any possible combination of such. Is that bad practice to handle code like that?

Example

if( mode == Modes.EDIT ){
  try {user = userBo.findById(id).get(0); }
  catch(Exception e) { }
  try{
    result = this.initializeEntityById(accountDao, id);
    if( !result.equals(SUCCESS) ){
      return result;
    }   
  }
  catch(Exception e){ }
}

In this example the variable in concern is 'id' where I'm not sure if the value coming in is valid and on the front end it doesn't really matter because the code handles whatever comes in and provides correct display.

So the question really is:

Is this a bad practice with the empty catch's?
Is there any potential instability that could occur that I'm not realizing?
Is there a better way to achieve what I'm looking to get at?

IMO: 1. It is a bad practice since you must know what problem happened, so it would be better to **always** handle the exception. 2. In your current example, looks like not, but the code will evolve in time and might have potential instabilities. 3. At least log the exception with a proper logger (not a `System.out.println`). — Luiggi Mendoza, Jul 24 '13 at 15:19

Vivin Paliath · Accepted Answer · 2013-07-24T15:22:41.273

Yes it's always bad practice since you have no idea what went wrong where. You should at least log the exception.
The instability is that when something goes wrong, you have no idea what is wrong with your code.
It's never desirable to use exceptions for control-flow. The performance is atrocious, and exceptions should only be used for exceptional circumstances. Here's what you can do:
1. Make the exception part of the method signature and let a higher level handle it.
2. Catch the exception, but wrap it in a semantically-appropriate exception and rethrow it so a higher level can handle it.
3. Handle it. This can also be done in multiple ways:
  1. Don't let the exception happen: instead of catching the exception, perform an inspection on the data to see if it can cause an exception. For example, in your case I think you should have a method like userBo.existsWithId(id) which will return a boolean that says whether the user exists. Or have the findById return null if the user cannot be found, and check to see if user == null. I think this is your best bet.
  2. Recover from the exception in some sane way (depends on your business logic).

Thanks for the indepth answer. I don't know why I didn't think of just doing that boolean check to avoid that. — gcalex5, Jul 24 '13 at 15:27
It's not *always* bad. If you want to return a fixed date Java makes you catch an exception which will never occur: `return new SimpleDateFormat("yyyy-MM-dd").parse("2999-12-31");` — Marc, Nov 09 '17 at 17:43
@Marc what if someone changes either of those strings? You want to at least log it; otherwise things fail silently. — Vivin Paliath, Nov 09 '17 at 23:24

score 1 · Answer 2 · edited Jun 20 '20 at 09:12

1

This is bad practice.

There's no instability, per se, but with empty catches, nothing is being done about the exception, which could leave an object in an inconsistent state if some aspects didn't get processed due to the exception.

With that said, empty catch blocks make for very difficult debugging. Even in production code, you should include a basic "notification" for most exceptions.

In testing code, use e.printStackTrace( in every catch block that does nothing otherwise.

edited Jun 20 '20 at 09:12

Community

1
1

answered Jul 24 '13 at 15:17

nanofarad

40,330
4
86
117

2

To whomever just drive-by downvoted all answers to this question: Please explain your issue with the answer content. – nanofarad Apr 07 '16 at 20:42
1

I'm speculating that they downvoted duplicate (more or less) answers without checking the timestamps – Zim-Zam O'Pootertoot Apr 08 '16 at 13:02

amicngh · Answer 3 · 2013-07-24T15:24:01.303

1) Is this a bad practice with the empty catch's?

Yes this is not a good practice.

2) Is there any potential instability that could occur that I'm not realizing?

If you anything goes wrong and any exception thrown then you will not be able to identify what goes wrong because in catch block you are not doing anything so it is assumed to be handled.

3) Is there a better way to achieve what I'm looking to get at?'

Try to log the exception stacktrace in catch block . or throw it again

e.g. e.printstacktrace();

James Dunn · Answer 4 · 2013-07-24T15:28:49.700

Yes, this is bad practice.
If an exception is thrown, it should be handled somehow, and the catch block is meant to hold the handling code. At the very least, if you don't need recovery code and alternate logic in your method to handle a caught exception (which would be rare), you should log the exception so you know it happened.

You can read an excellent article on handling exceptions here:

http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html?page=2

I found the second page to be especially helpful.

Try with empty Catches

4 Answers4

This is bad practice.

Linked