Question

我似乎总是走到一条十字路口，在那里我不知道如何处理异常而不重新投掷给调用者。

有没有更好的方法来处理以下情况？

private DataHandler retrieveFromGridFS(ObjectId id) throws IOException
{
    GridFS gridFS = new GridFS(getDBReference());        
    GridFSDBFile out = gridFS.find(id);

    File temp = File.createTempFile(
            (String)out.getMetaData().get("productName"), 
            (String)out.getMetaData().get("productType"));

    out.writeTo(temp);

    return new DataHandler(new FileDataSource(temp));        
}

上述private方法可以抛出IOException。

像这样使用这种方法：

public DataHandler retrieveProduct(String productId) throws IOException
{
    ObjectId id = new ObjectId(productId);
    DataHandler handler = null;

    try
    {
        handler = retrieveFromGridFS(id);
    }
    catch(IOException ex)
    {
        logger.error(ex);
        throw new IOException("A problem occurred retrieving product.");
    }

    return handler;
}

我被迫重新投掷，所以我不冒险返回null。

Answer 1

这完全取决于。

首先，您是否真的希望将IOException渗透到上层，或者您是否希望在特定于应用程序的异常中封装可能出现在较低层的各种异常？

您是否需要能够从此例外中恢复？如果没有，RuntimeException更合适吗？（即使你做需要异常可以恢复，你是否在一个提供高级声明性异常处理的环境中运行？）

使用NullObject模式避免返回null会更有意义吗？

（等等:)

Answer 2

一般来说，如果您能回应发生的事件，请抓住例外。防爆。假设你有代码在失败时重试连接。然后你可能有一个捕获IOException并重试x次的循环。上面的调用者并不关心潜在的失败。

当发生无法处理的异常时，你不会这样做。基本上你是在推卸责任。

最近，我倾向于避免重新抛出异常，因为在大多数情况下，其他异常消除对象。我通过经验发现，它在大多数时候并没有真正增加价值。

Answer 3

什么？在我看来，retrieveProduct只是一个方便的函数来执行retrieveFromGridFS所做的任何操作，但使用String作为标识符而不是ObjectId。那么它不能提出的例外情况应该与retrieveFromGridFS的例外情况相同吗？

如何处理本地化异常？

3 个答案: