异常处理反模式

2

catch (...) in C++。

可能使你的代码看起来稳定的最糟糕的方式...

这同样适用于任何其他语言，在这里你抓你不应该有异常，只是他们吞下默默地以隐藏错误来自用户。但(...)通常用于捕获异常，如NULL指针取消引用或拒绝访问，这意味着吞下的错误可能会稍后以可能看起来与问题根本无关的方式显现。

来源

2011-07-06 07:17:37 eran

3

为清理逻辑

从析构函数在清理代码投掷。这个是非常糟糕的，因为a。）从析构函数中抛出通常是不好的，b）因为即使你能够捕获它，关于它也没有什么可做的。

File::~File() 
{ 
    if (!close(fd_)) { 
     throw FileIOException("Could not close descriptor.", fd_); 
    } 
}

来自地狱的UI

try { 
    // ... lots of UI logic here ... 
} catch (Exception error) { 
    alert("This program has performed an illegal operation and needs to quit."); 
    System.exit(-1); 
}

重试没有退避

bool has_connected = false; 
while (!has_connected) { 
    try { 
     EstablishConnection(); 
     has_connected = true; 
    } catch (...) { 
     // IGNORE 
    } 
    }

来源

2011-07-06 07:28:45

+0

没有回退的重试会将性能问题转化为可用性问题。好的。 –

1

我最大的忌讳是建立一个例外的继承层次结构，其中后代的关系提供小轴承关于是否应该发现一个例外。关于预定义的异常没有太多的工作要做，但是我的首选是避免抛出这些异常，而是为调用者假定系统状态正常的情况定义新的异常，除了例程所暗示的范围之外不会成功返回，而不是系统状态被抛弃的那些。例如，如果某个方法应该打开一个文件并返回一个新的文档对象，但解析该文件时存在一些问题，则不应该杀死整个应用程序。它应该让用户知道该文件无法打开，然后像用户未试图打开文件那样继续。这与文件没有打开的原因无关。问题是应用程序状态是否已损坏。不幸的是，没有一个标准例外很好地处理这个问题。

来源

2011-07-06 23:36:02 supercat

+0

也许这是因为无法打开文件并不是一个真正的例外事件？这不应该是常规错误处理的一部分吗？ –

+0

@Sedate Alien：有时它应该是例外，有时候不是;这就是Try/Do模式的用途。但是，在解析例程中，通常会使用异常来中止不成功的解析，而不是测试每个单独的子操作以获得成功。错误检查几乎是解析例程长度的两倍，这种情况并不少见;如果错误检查唯一能做的就是中止解析，使用异常可以将代码大小减半。 – supercat

3

这是一个不完全不同于我以前见过的东西。

try { 
    methodThatThrowsSomeException1(); 
    methodThatThrowsSomeOtherException2(); 
    methodThatThrowsSomeOtherException3(); 
    methodThatThrowsSomeOtherException4(); 
    methodThatThrowsSomeOtherException5(); 
    methodThatThrowsSomeOtherException6(); 
    ... 
    methodThatThrowsYetAnotherException20(); 
} catch (Throwable e) { 
    log.error("There was a problem reading the user role"); 
    role = PRIVILEGED; 
}

来源

2011-07-07 00:12:05

1

在共享库中使用意图从多种语言/ C++方言中使用的例外。由于C++编译器无法保证您不会意外地将异常抛出回调用方（与Java不同），您只需设置自己的崩溃。

来源

2011-08-23 06:47:32

异常处理反模式

回答

相关问题