在Java（GWT）中处理异常

Question

我目前正在处理异常处理，我想知道应该在哪里捕获它们。

这是GWT应用程序中的堆栈：

• 具有可以抛出NumerFormatExeption（FormHelper.java）的方法的助手
• 使用此帮助器的小部件（CostWidget.java）
• 演示者，调用此小部件以检索数据（BuildingPresenter.java）

FormHelper.java

public static Integer prepareIntegerForDb(String string) {
    return Integer.parseInt(string);    
}

CostWidget.java

public DetailCostProxy getCostDetail() { 
    ...
    costDetail.setQuantity(FormHelper.prepareDoubleForBd(qtTextBox.getText()));
    ...
    return costDetail;
}


public List<DetailCostProxy> getCostList() {
    ...
    costDetails .add(ligneCout.getCostDetail());
    ...
}

BuildingPresenter.java

public void saveBuilding(final BuildingProxy inter, final CollectRequestContext savecontext) {

    savecontext.save(display.getCostWidget().getCoutList()).fire(new Receiver<BuildingProxy >() {....

}

我在考虑：

1）在助手中添加“ throws NumberFormatException”到prepareIntegerForDb（）

2）在小部件中的getCostDetail（）中添加“ throws NumberFormatException”

3）在小部件中的getCostList（）中添加“ throws NumberFormatException”

4）在演示者中缓存异常（在saveBuilding中）

目的是：

• 记录异常
• 向用户提供一条消息，指出出现了问题

考虑到一个示例，您对这种方法有何看法，我将不得不将此模式应用于整个应用程序（超过20位演示者）。

我的方法是处理GWT中异常的好方法吗？ 还是应该直接在助手或其他地方记录错误？

Answer 1

prepareIntegerForDB（）应该抛出异常。 当Integer.parse（）失败并且您不必实际抛出异常时，会自动发生这种情况。

getCostDetail（）应该显式捕获并引发异常，并可能扩展引发异常的原因。 诸如“ 费用不是可读格式 ”之类的东西。 该方法仅负责那一行。

getCostList（）应该捕获并处理异常。 该方法负责整个集合。 如果您在此处不处理错误数据，则将丢失正确数据。 这是处理不良数据的一种方法。

public List<DetailCostProxy> getCostList() {
    ...

    try {
        DetailCostProxy cost = lineCount.getCostDetail()
        costDetails.add(cost);
    catch (NumberFormatException e) {
        costDetails.add(null);
    }

    ...
}

最后，向用户显示数据的方法应在显示之前解释传递给它的数据。 如果您使用我上面的示例，则就像检查空值一样简单。

Answer 2

考虑到一个示例，您对这种方法有何看法，我将不得不将此模式应用于整个应用程序（超过20位演示者）。

添加throws NumberFormatException声明不会帮助您“向用户提供一条消息，指出发生了问题”。 NumberFormatException-s是RuntimeException-s因此throws明甚至不会强制try/catch使用这些方法的代码。

我的方法是处理GWT中异常的好方法吗？ 还是应该直接在助手或其他地方记录错误？

4）在演示者中捕获异常（在saveBuilding中）

目的是：

• 记录异常

• 向用户提供一条消息，指出出现了问题

这个问题并非专门针对GWT。

如果您知道如何处理异常，则捕获异常是一个好主意。

如果将错误告知用户，则需要使用户能够决定如何处理该问题（例如，弹出消息，建议采取两种措施来恢复应用程序的执行）。