异常处理反模式：为什么log和return null是反模式

Question

An article on Exception handling anti-patterns mentions (Refer: https://today.java.net/article/2006/04/04/exception-handling-antipatterns ) that Log and Return Null is an anti-pattern. The reason given is “Instead of returning null, throw the exception, and let the caller deal with it. You should only return null in a normal (non-exceptional) use case”

According to the article, following code is a bad programming practice and anti-pattern

catch (NoSuchMethodException e) {
  LOG.error("Blah", e);
  return null;
}

catch (NoSuchMethodException e) {
  e.printStackTrace();
  return null;
}

I request some more explanation. I can understand why just returning null is an anti-pattern as it swallows the exception losing the information forever. But with LOG.error("Blah", e); and e.printStackTrace();, the information is logged or printed and is not lost – so why it is an anti-pattern?

Answer 1

The caller gets no additional semantic information about what error occurred, nor why it occurred. Did they pass bad input? In that case, give them a client-focused error (which will translate better across RPC or some other kind of remote-invocation). Did some dependent upstream service go away? Throw a semantic exception so that the caller can provide useful feedback to the user (eg, "The database is unavailable. Please call the help desk at..."). null makes it impossible to respond to errors in meaningful ways - it just becomes the catch-all "an error occurred".

Answer 2

The article referenced conflates the use of exceptions and null usage. In general swallowing an exception is an anti-pattern. However, in some situations if the catch block is providing information or side-effects thru other means it is a valid approach. For example, the code can create an exception handler to a visitor. Also, throwing an exception is meaningless if there is no one to catch it. Are there scenarios where this is true?