java 尝试使用空的捕获

Try with empty Catches

提问by gcalex5

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?

假设我有一个 try 语句和空 catch 是不好的做法吗？例如，说我有 2 次单独的尝试，其中一个可能失败但另一个成功或两者都成功或任何可能的组合。处理这样的代码是不好的做法吗？

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.

在这个例子中，关注的变量是“id”，我不确定传入的值是否有效，在前端它并不重要，因为代码处理传入的任何内容并提供正确的显示。

So the question really is:

所以问题真的是：

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

1. 这是空渔获物的不良做法吗？
2. 是否存在我没​​有意识到的潜在不稳定性？
3. 有没有更好的方法来实现我想要的？

采纳答案by Vivin Paliath

1. Yes it's always bad practicesince you have no idea what went wrong where. You should at least log the exception.
2. The instability is that when something goes wrong, you have no idea what is wrong with your code.
3. 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 booleanthat says whether the user exists. Or have the findByIdreturn nullif 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).

1. 是的，这总是不好的做法，因为您不知道哪里出了问题。您至少应该记录异常。
2. 不稳定性是当出现问题时，你不知道你的代码出了什么问题。
3. 永远不要为控制流使用异常。性能很差，异常应该只用于特殊情况。您可以执行以下操作：
   1. 将异常作为方法签名的一部分并让更高层处理它。
   2. 捕获异常，但将其包装在语义适当的异常中并重新抛出，以便更高级别可以处理它。
   3. 处理它。这也可以通过多种方式完成：
      1. 不要让异常发生：不是捕获异常，而是对数据进行检查，看看它是否会导致异常。例如，在你的情况下，我认为你应该有一个方法userBo.existsWithId(id)，它会返回一个boolean表示用户是否存在的方法。或者如果找不到用户，则findById返回null，并检查是否user == null。我认为这是你最好的选择。
      2. 以某种理智的方式从异常中恢复（取决于您的业务逻辑）。

回答by nanofarad

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.

话虽如此，空的 catch 块使调试变得非常困难。即使在生产代码中，您也应该为大多数异常包含一个基本的“通知”。

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

在测试代​​码中，e.printStackTrace(在每个不执行任何其他操作的 catch 块中使用。

回答by amicngh

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

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?

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.

如果您出现任何问题并抛出任何异常，那么您将无法识别出了什么问题，因为在 catch 块中您没有做任何事情，因此假定它已被处理。

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

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

尝试在 中记录异常堆栈跟踪catch block。或者再扔一次

e.g. e.printstacktrace();

回答by James Dunn

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:

是的，这是不好的做法。
如果抛出异常，应该以某种方式处理它，catch 块用于保存处理代码。至少，如果您的方法中不需要恢复代码和备用逻辑来处理捕获的异常（这种情况很少见），您应该记录异常以便您知道它发生了。

您可以在此处阅读有关处理异常的优秀文章：

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

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

I found the second page to be especially helpful.

我发现第二页特别有用。