问题标签 [exception-handling]

结构化异常处理不好吗？处理异常的正确方法是什么？

编辑：使用 C# 在 .NET 中进行异常处理。

我通常有一组特定的异常类（DivideByZeroException、ArrayTypeMismatchException）并且没有通用的“catch (Exception ex)”。

这背后的想法是，我预计会发生某些类型的异常，并在它们发生时定义特定的操作，并且意外的异常会在界面（Windows 或 Web）上出现。这是一个好习惯吗？

在决定是让方法躲避异常（即：让异常传播）还是在收到异常后处理它时，您使用什么指导方针？

这是我要问的一个例子

如果我有三个方法method1、2、3和3。Method1调用Method2，后者调用Method3。并且该异常仅在方法3中引发，我应该让异常向上传播如下（请原谅我的伪java；））

一旦异常引发如下，我什么时候应该处理它

我有以下代码

假设 ExceptionType1 由第 1 节处理的代码抛出。在第 1 节处理之后，我可以将控制权传递给第 2 节/第 3 节吗？那可能吗？

因此，我对尝试从程序自动收集数据的概念感到满意——即，当出现问题时，弹出一个对话框，要求用户发送报告。

我在 MS Visual Studio C# 中工作。

从实现的角度来看，在我的主 program.cs 文件中放置一个 try/catch 循环是否有意义，在应用程序运行的位置周围？像这样：

或者将 try/catch 循环放在代码片段中以捕获更具体的异常类型是否有意义？（我认为不是因为这是一个新应用程序，并且放入更具体的异常捕获意味着我知道会出现什么问题......我不知道，这就是为什么上面对我来说似乎有意义.)

-阿迪娜

如何根据特定的程序条件将 a 绑定std::ostream到其中一个std::cout或一个对象？std::ofstream尽管由于许多原因这无效，但我想实现在语义上等同于以下内容的东西：

我见过一些不是异常安全的示例，例如来自http://www2.roguewave.com/support/docs/sourcepro/edition9/html/stdlibug/34-2.html的示例：

有谁知道更好的，异常安全的解决方案？

我在一个项目中发现了一些代码，看起来像这样：

我不明白为什么要捕获异常。如果不是，应用程序将简单地退出并打印异常。

您认为有什么好的理由在这里捕获异常吗？

编辑：我同意打印异常错误是件好事。但是，重新抛出异常不是更好吗？我有一种感觉，我们在这里吞下了它……

假设我有一个将某种对象作为参数的方法。现在说如果这个方法传递了一个空参数，这是一个致命错误，应该抛出一个异常。我是否值得编写这样的代码（记住这是一个简单的例子）：

或者当它调用 x.doSomething() 时仅仅依靠它抛出 NullException 对我来说是安全的吗？

其次，假设 someMethod 是一个构造函数，并且 x 在调用另一个方法之前不会被使用。我应该立即抛出异常还是等到需要 x 后再抛出异常？

我想知道是否存在（在 Java 世界中）能够使用以下功能拍摄 JVM 当前状态的快照：

• 在抛出异常时执行此操作。
• 捕获局部变量、方法的参数等。
• 将它放在一个方便的文件中，该文件可用于在 IDE 中提取或重现源代码中的情况。

前两个功能是必需的（第三个会很棒）。并且它必须适合生产使用（因此，调试器没有办法）。

在问这个之前，我已经搜索了万维网（尽可能长），我发现了一些指针：

• Cajoon Interceptor：正如Dzone 帖子中所说，它是一个满足三个要求的被动 JVM 代理！但是，它有两个缺点：您必须为此付费，并且网站已关闭（也许没有机会支付任何费用）。
• AviCode Intercept Studio：Cajoon 的 .NET 等价物。只是为了提供一些见解。
• JavaFrame：好的，这是一条推文，但它指向一个可用的 SVN 存储库，其中包含看起来不错的 JVM 代理的源代码（在 MIT 许可下）（我将尝试一下）。

那么，也许我正在寻找一个不存在的解决方案？这并不紧急，但我有一个项目的想法，探索这条“未知”（？）路径并获得真实的东西会很棒。

似乎很清楚它将是一个 JVM 代理（例如，来自 JVMTI 的异常事件）。

最后，我将重点介绍 Wikipedia 异常处理文章中的以下段落：

在 Java 或 .NET 等运行时引擎环境中，存在附加到运行时引擎的工具，每次发生感兴趣的异常时，它们都会记录在引发异常时内存中存在的调试信息（调用堆栈和堆值）。这些工具称为自动异常处理或错误拦截工具，并为异常提供“根本原因”信息。

这就是想法。我希望有人能给我一些见解，或者将来有人会从这篇不起眼的帖子中得到启发:)

谢谢！

或者任何其他将 gui 小部件作为第一个调用端口的设计，未处理的异常会杀死应用程序？

我们都想要一个主要的：“抓住所有”以节省面子（尽管在大多数情况下，这不应该具有“继续”功能），但是不可能使用作为第一个调用端口的 gui 小部件轻松实现一个。这个设计有缺陷还是我在某个地方漏掉了一个技巧？

我之所以问这个问题是因为我正在阅读该语言的设计者的一篇文章，他说异常处理应该是集中的，而我首先想到的是 WinForm 事件机制，这变得很困难。

WinForm/GUI 团队是在听他的，还是到那时可能为时已晚？

我的技术负责人坚持这种异常机制：

这里的 1242 是我们处理 OurException 以外的异常的 catch 方法的标识符。项目中的每个 catch 块都必须有一个唯一的标识符，这样我们就可以通过查看日志来知道异常发生在哪里。

对于每个方法，我们都必须捕获 OurException 并抛出它。如果抛出了其他类型的异常，我们必须在重新抛出它之前记录它并用 OurException 屏蔽它。

这是一个合理的方法吗？如果有的话，有什么更好的选择？

编辑：我被告知堆栈跟踪在发布模式下不会产生有意义的结果。您是否建议捕获和抛出通用异常可以？

编辑2：谢谢大家。我用你的回答作为我反对这个论点的一部分，但我被告知你没有足够的经验，不知道如何处理现实生活中的情况。我必须走这条路。