我经常遇到同样的问题，当一个有返回值的函数捕获了异常时，我不知道该返回什么。下面的代码片段说明了我的问题。
public Object getObject(){
try{
...
return object;
}
catch(Exception e){
//I have to return something here but what??
return null; // is this a bad design??
}
}
我的问题是：
谢谢。
如果你真的无法处理异常，就不要捕获它。记录日志并不算是处理错误。最好通过抛出异常将其上抛到可以处理的人手中。
如果你必须返回一个值，并且 null 是唯一明智的选择，那么没有什么问题。只需记录下来，并向用户清楚地说明应该做什么。编写一个单元测试，演示抛出异常，这样接替你的开发人员就能看到接受的惯用法是什么。它还可以测试确保你的代码在应该抛出异常时确实抛出了异常。
Foo foo = bar.getFoo();
if (foo != null) {
// do something with foo
}
throws子句，要么完全删除try/catch块，要么保留try/catch块（如果有必要，例如需要处理多个异常），并将异常原样重新抛出或包装在自定义异常中。这是你的代码，而且并不是一个坏的解决方案。但是如果你要分享你的代码，就不应该使用它，因为它可能会抛出意外的异常（例如空指针异常）。
当然，你可以使用
public Object getObject() throws Exception {}
这可以为父函数提供可用信息，并警告可能发生的问题。
最终，异常应该由控制器捕获。
将 <null> 传递给控制器没有意义。
最好将原始异常抛出/返回到堆栈上。
基本上我会赞同Duffymo的看法，稍微加上一点：
就像他所说的，如果你的函数调用者不能处理异常并恢复，那么不要捕获异常。让更高级别的函数来捕获异常。
如果调用者需要采取某些措施但应该适当地自己终止，只需重新抛出异常。例如：
SomeObject doStuff()
throws PanicAbortException
{
try
{
int x=functionThatMightThrowException();
... whatever ...
return y;
}
catch (PanicAbortException panic)
{
cleanUpMess();
throw panic; // <-- rethrow the exception
}
}
你也可以重新打包异常，例如...
catch (PanicAbortException panic)
{
throw new MoreGenericException("In function xyz: "+panic.getMessage());
}
正如Joshua Bloch在书 "Effective Java" 中所说，null是Java的关键字。
这个单词表示一个内存位置没有指向任何其他内存位置的指针：我认为最好将有关功能域的行为（例如：您等待一种A对象，但却收到一种B对象）与低级域的行为（例如：内存不可用）进行分开编码。
在您的例子中，我会修改代码：
public Object getObject(){
Object objectReturned=new Object();
try{
/**business logic*/
}
catch(Exception e){
//logging and eventual logic leaving the current ojbect (this) in a consistent state
}
return objectReturned;
}
缺点是在每次调用getObject()时创建一个完整的对象（然后在返回的对象不被读取或写入的情况下）。
但我更喜欢拥有相同的无用对象，而不是NullPointerException，因为有时这个异常很难修复。
if (x!=null) {...}语句块。不要自己制造空指针异常。
catch(Exception e)几乎总是一个不好的主意。如果try{}块中的代码编写得很好，你应该对它将抛出哪个异常有一个很好的想法，然后你可以只捕获那个异常。 - Tyler