Questions tagged «exception-handling»

我正在编写一个简单的小程序来通过网络传输MIDI。我知道程序会遇到传输问题和/或其他无法预测的异常情况。 对于异常处理，我看到两种方法。我应该编写程序以便它： 发生问题时失败并发出爆炸声， 或者 它是否应该忽略错误并继续进行，以牺牲数据完整性为代价？ 用户合理地期望哪种方法？ 有没有更好的处理异常的方法？ 另外，我是否处理网络连接（即，我可以合理预期出现问题的地方）是否会影响我处理异常的决定？

20 exception-handling 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 如果我们将异常称为错误，那么为什么不首先将其称为错误而不是异常呢？ 如果在代码中将其称为异常，则在发生时将其称为错误。那么，为什么不首先将其称为错误？ 感谢您的任何回答或评论。

18 bug  debugging  issue-tracking  exceptions  exception-handling 

作为一名Java程序员，我一直对Unchecked Exception持批评态度。通常，程序员使用它作为编码简便性的途径，只会在以后造成麻烦。此外，与未检查的对等程序相比，具有检查的异常的程序（尽管不整洁）非常健壮。 令人惊讶的是，在Scala中，没有什么叫做“检查的异常”。Scala中所有未选中和未选中的Java都未选中。 做出此决定的动机是什么？对我来说，在使用任何外部代码时都会遇到很多问题。并且，如果偶然地文档很差，则将导致KILL。

17 java  scala  exceptions  exception-handling 

如果System.Exception认为投掷很糟糕，为什么一开始就没有Exception做出abstract？ 这样，将无法调用： throw new Exception("Error occurred."); 这将强制使用派生异常来提供有关发生的错误的更多详细信息。 例如，当我想为库提供自定义异常层次结构时，通常会为我的异常声明一个抽象基类： public abstract class CustomExceptionBase : Exception { /* some stuff here */ } 然后是一些派生的异常，其目的更加具体： public class DerivedCustomException : CustomExceptionBase { /* some more specific stuff here */ } 然后，在调用任何库方法时，可以使用此通用try / catch块直接捕获来自库的任何错误： try { /* library calls here */ } catch (CustomExceptionBase ex) …

17 c#  exception-handling  abstract-class 

第二，我想知道是否有人知道异常（在异常控制流领域）和异常（例如在Java中使用）之间的区别。 但是它们是否可以通过终止用户程序来从根本上防止系统崩溃？

16 exceptions  exception-handling 

我遇到试图检索对象的情况。如果查找失败，则我有多个后备，每一个都可能失败。因此，代码如下所示： try { return repository.getElement(x); } catch (NotFoundException e) { try { return repository.getSimilarElement(x); } catch (NotFoundException e1) { try { return repository.getParentElement(x); } catch (NotFoundException e2) { //can't recover throw new IllegalArgumentException(e); } } } 这看起来很难看。我讨厌返回null，但是在这种情况下会更好吗？ Element e = return repository.getElement(x); if (e == null) { e = repository.getSimilarElement(x); …

14 java  exception-handling 

具体询问默认构造函数 考虑到构造函数会初始化一个对象的所有数据，如果我创建了一个未经适当初始化就无法使用的类，那么默认构造函数是否就没有用？考虑： // A class for handling lines in a CSV file class CSV_Entry { private: unsigned num_entries; std::string string_version; std::vector<std::string> vector_version; ...etc public: CSV_Entry(); CSV_Entry(const std::string& src_line); // returns a vector copy of the original entry std::vector<std::string> get_vector_snapshot(); } int main( void ) { ...etc CSV_Entry example = CSV_Entry(); …

14 exceptions  exception-handling  initialization  constructors 

我已经读到我们应该只捕获可以处理的异常，这使得捕获基本异常类（在这种情况下为C＃）不是一个好主意（除其他原因之外）。我目前是一个项目的一部分，到目前为止，除了捕获到的基本异常之外，我什么都没有看到。我提到这样做是不明智的做法，但是响应是“此服务需要24/7运行，因此是这样。” 由于我对如何正确处理需要24/7运行的程序中的异常没有很好的反应，所以我现在在这里。我没有找到有关如何处理需要全天候运行的“关键”程序/服务中的异常处理的任何信息/建议（在这种情况下，我认为如果该服务关闭一分钟可能会没事的或两个，所以甚至都不重要）。我了解这取决于程序的确切性质。与在线游戏的日志扫描器相比，可能导致生命危险的程序的要求有很大不同。 两个例子： 1：为英国铁路客户提供的提前输入服务，当他们在线搜索火车站时使用。 2：一个程序，该程序基于从轨道，火车等中的各种传感器提供的实时信息，自动控制上述铁路的铁路开关。 如果第一个程序崩溃了一到两分钟，它可能不会引起重大问题，而后者可能会导致人员伤亡。关于如何处理每个建议？指向哪里可以找到有关此问题的更多信息和想法？

14 exception-handling 

您能推荐一种设计模式/方法来暴露/容忍/从系统错误中恢复，异常处理（Java，C ++，Perl，PHP）吗？ 一些错误需要报告。 某些错误可以在内部处理（通过重试或不重要的处理（可以忽略））。 您如何构造代码以捕获它们？ 但是所有错误都需要记录。 有哪些最佳实践？ 为了模拟它们能够完全测试受它们影响的组件？ 适用于几种现代编程语言的一般非编程语言特定问题，但将欢迎使用Java，C ++，PHP和Perl进行模式，方法和哲学的示例说明。 （也在stackoverflow中问过：https : //stackoverflow.com/questions/7432596/recommend-a-design-pattern-approach-to-exposed-tolerating-recovering-from-system， 但我认为也应该在程序员中提出，因为我认为程序员的问答涵盖了更广泛的软件/编程问题，而stackoverflow则更多地是关于技术实现（IMHO）。

13 design-patterns  philosophy  error-handling  exception-handling 

在公司的一些应用程序中，我们使用自定义记录器。它相当健壮，尽管将来我们可能会用NLog之类的东西来代替它。记录器的任务之一是记录应用程序中遇到的任何异常。 我一直担心的一个问题是，记录器中的异常处理允许出现静默故障。也就是说，如果未针对给定的异常编写日志（由于记录器中的错误），那么我应该如何处理该异常并（以某种方式）将异常记录到记录器本身中？ 假设WriteLog函数引发异常。我应该尝试多次调用该函数还是直到不引发异常之前？我是否应该尝试使用记录器编写引发的异常（这很可能会导致异常完全消失……）？除了第一次实现自定义记录器时，我很幸运没有遇到这种情况。另一方面，我目前无法知道记录器是否未能记录应用程序异常（由于其自身的异常）。 我已经尝试过在线和在一些SE网站上进行搜索，但是到目前为止，由于所有帖子都处理记录器中的错误（但不记录潜在的异常以及如何记录它们）或记录器外部的异常，到目前为止，这种方法是徒劳的。

12 design-patterns  exceptions  exception-handling  logging  error-handling 

以防万一代码的另一部分没有正确编码，是实现无用异常处理的好习惯吗？ 基本例子 一个简单的，所以我不会让每个人都放松:)。 假设我正在编写一个应用程序，它将显示一个人的信息（姓名，地址等），数据是从数据库中提取的。假设我是UI部分的编码人员，而其他人正在编写DB查询代码。 现在，假设您的应用程序规范说明如果该人员的信息不完整（例如，数据库中缺少该名称），则对查询进行编码的人员应通过为缺失字段返回“ NA”来处理此问题。 如果查询的编码不正确怎么办？如果编写查询的人为您处理了不完整的结果，并且当您尝试显示信息时一切都崩溃了，因为您的代码不准备显示空的东西怎么办？ 这个例子很基础。我相信你们大多数人会说“这不是您的问题，您不应对这次崩溃负责”。但是，仍然是崩溃的一部分。 另一个例子 假设现在我是编写查询的人。规范与上面的说法不同，但是在向数据库中添加人员时，编写“插入”查询的人应确保所有字段均完整，以避免插入不完整的信息。我应该保护我的“选择”查询以确保为UI家伙提供完整的信息吗？ 问题 如果规范中没有明确指出“此人是负责处理这种情况的人”，该怎么办？如果第三方实现了另一个查询（类似于第一个查询，但在另一个DB上）并使用您的UI代码显示该查询，但在他的代码中不处理这种情况怎么办？ 即使我不是应该处理这种情况的人，我也应该采取必要的措施来防止可能的崩溃吗？ 我不是要寻找“他是崩溃的负责人”之类的答案，因为我不想在这里解决冲突，我想知道，如果我保护我的代码免受情况影响，这不是我的责任处理？在这里，一个简单的“如果空着做某事”就足够了。 通常，此问题解决了冗余异常处理。我之所以这样问，是因为当我一个人在一个项目上工作时，我可能会在连续的函数中编写2-3次类似异常处理的代码，以防万一我做错了什么，让一个糟糕的情况解决了。

12 language-agnostic  validation  exception-handling 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 5年前关闭。 我认为程序的两个主要问题是代码结构/组织和错误处理。我正在阅读Code Complete 2，但是我需要阅读一些有关潜在问题的书籍。 例如，在一个网站上，如果仅当用户通过javascript篡改数据时才有可能发生某些事情，您是否为此写信？另外，什么时候不捕获错误？当您编写一个期望一个字符串和一个int作为输入的类，而它们不是一个字符串和int时，您是否进行检查，还是让它冒泡到传递了错误参数的调用方法？ 我知道这是一个广泛的主题，在这里不能一口气回答，所以我要寻找的是一本通常被教为教授适当的异常处理实践的书或资源。

12 programming-practices  books  exceptions  exception-handling 

这是一个相关的问题： 在返回不良样式/危险之后，使用finally子句进行工作吗？ 在引用的Q中，最终代码与所使用的结构和预取的必要性有关。我的问题有所不同，我认为这与广大受众密切相关。我的特定示例是C＃winform应用程序，但这同样适用于C ++ / Java。 我注意到很多try-catch-finally块，其中有很多与异常无关的代码以及埋在该块中的异常处理/清除。而且，我会偏向于使用非常紧密的try-catch-finally块，并将其代码与异常和处理紧密相关。这是我所看到的一些示例。 尝试块将设置许多初步调用和变量，从而导致可能引发的代码。日志信息将被设置并在try块中运行。 最后，块将具有表单/模块/控件格式化调用（尽管应用程序即将终止，如catch块所示），以及创建新对象（例如面板）。 大致： methodName（...） { 尝试 { //该方法的大量代码... //可能抛出的代码... //该方法还有更多代码和返回值... } 抓住（某物） {//处理异常} 最后 { //由于异常而进行一些清理，将事情关闭 //有关所创建内容的更多代码（忽略任何异常都可能引发）... //可能会创建更多对象 } } 该代码有效，因此具有一定的价值。它没有很好地封装，逻辑有点混乱。我（痛苦地）熟悉了代码移位和重构的风险，因此我的问题归结为想要了解其他人对类似结构的代码的经验。 不良的风格是否有理由进行更改？有没有人被类似的情况严重烧死？您是否愿意分享糟糕经历的细节？别说是因为我反应过度，风格还不错吗？获得整理事物的维护利益？

11 design  exception-handling  coding-style 

使用我们的公共SDK，我们倾向于提供非常有用的消息，说明为什么发生异常。例如： if (interfaceInstance == null) { string errMsg = string.Format( "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.", ParameterInfo.Name, ParameterInfo.ParameterType, typeof(IParameter) ); throw new InvalidOperationException(errMsg); } 但是，由于倾向于将重点放在错误消息而不是代码在做什么，这往往会使代码流变得混乱。 一位同事开始重构一些引发如下异常的异常： if (interfaceInstance == null) throw EmptyConstructor(); ... private Exception EmptyConstructor() …

11 c#  .net  clean-code  exception-handling 

对于if...else带有异常处理的典型包装，是否建议使用以下示例来避免代码重复？ try { if (GetDataFromServer()) { return ProcessData(); } else { throw new Exception(); } catch(Exception ex) { return null; } 代替... try { if (GetDataFromServer()) { return ProcessData(); } else { return null; } } catch(Exception ex) { return null; } 我知道会有轻微的性能下降，但是我想知道这是否可以接受。我目前使用第二种方法-特别是在需要以不同方式处理特定异常的情况下-但我想知道第一种方法是否适合简单情况。

10 c#  exception-handling