在.Net：
1）您是否将异常传播到全局错误处理程序，您在其中记录错误并显示消息框？我问的原因是你是否使用单个全局错误处理程序来捕获顶部的异常，你需要一堆Ifs来推断异常类型，然后显示一条可能友好的消息（例如对于filenotfound，你的文件提供没有找到，等等。）
我的winforms应用程序中有一个全局错误处理程序。对于我无法处理的任何异常，他们点击此处理程序，它记录异常并显示消息 - 但这是异常消息，有时我可能想要一些根据受众等不同的东西。
2）我只捕捉到我能处理的异常。但是，我的应用程序在用户可选路径中有一组文件夹。由于默认共享被锁定和审核等，任何丢失的文件都很少见，因此是“例外事件”。但是当用户在他或她自己的电脑上选择一个位置时，文件可能丢失，目录名称太长等等。我认为这更常见，所以不要在这里使用例外。但是之前我提到过我做过。对于这种冲突，是否有另一种方法来构建我的代码而不重复？
3）最后，还有一些我无法处理的例外情况（例如，文件不存在，无法处理，因为文件是特殊格式，只能由某些IT人员上传）。但这很少见。所以对于方法中的这些异常，我没有抓住它们。然而，当有人看到这一点时（尽管有人评论说它是在全球范围内被捕获的），其他开发者也不寒而栗。这是他们的无知吗？
Lasstly，解开堆栈跟踪意味着什么？
由于 }
答案 0 :(得分：1)
答案 1 :(得分：0)
当且仅当（1）条件存在于例程承诺引发异常的情况下，或（2）例程不能满足其承诺成功返回的后置条件时，应该引发异常。在许多情况下，可以松散地指定例程的后置条件，除非在堆栈溢出，线程中止或其他此类灾难的情况下几乎保证不会抛出，但在许多情况下它更有帮助提供更严格的保证。
例如，考虑从文件中读取'n'个字节的任务。可以编写一个例程来从文件读取'n'个字节，并返回读取的字节数（实际上，这是通常的范例，没有异常）。但是，尝试用这样的例程解析文件可能会令人讨厌。读取最多4个字节，查看是否读取了4个字节，如果是，则将它们转换为long，读取该字节数，查看是否读取了所有预期的字节等。每次读取后都要测试一下它成功地将所有预期的字节快速地变成了一件苦差事，它模糊了代码应该做的事情。另一种方法是有一个例程承诺，它只有在成功读取所请求的字节数时才会返回，否则抛出异常。在这种情况下，字节读取例程中更严格的承诺消除了代码中测试的需要，确保读取完全成功完成。
异常的主要好处在于，如果大量函数调用中的任何一个函数调用失败以满足预期的后置条件，则会导致相同的错误处理行为。如果在一个特定函数调用没有按预期运行时需要有特殊行为，那么简单地让例程返回行为是预期的还是意外的指示通常会更方便，并查看该结果。但是，如果有人会进行数十次函数调用，并且不会特别关心其中哪一个会产生意外行为，那么使用异常将无需对每个函数进行错误检查。