Questions tagged «exceptions»

我们使用异常来使代码的使用者以有用的方式处理意外行为。通常，异常是围绕“发生的情况”构建的，例如FileNotFound（我们无法找到您指定的文件）或ZeroDivisionError（我们无法执行1/0操作）。 如果有可能指定消费者的预期行为怎么办？ 例如，假设我们有fetch资源，该资源执行HTTP请求并返回检索到的数据。而不是像ServiceTemporaryUnavailable或之类的错误，RateLimitExceeded我们只会提出一个RetryableError建议，即消费者应该重试该请求，而不关心特定的失败。因此，我们基本上是在建议呼叫者采取一项行动-“该做什么”。 我们不经常这样做，因为我们不了解消费者的所有用例。但是，想象一下这是一个特定的组成部分，我们确实知道呼叫者的最佳操作过程-那么我们应该使用“做什么”方法吗？

19 exceptions 

在异常类上指定Exception的后缀感觉对我来说像是代码的味道（冗余信息-名称的其余部分表示错误状态，并且它继承自Exception）。但是，似乎每个人都这样做，这似乎是一种好习惯。 我想了解为什么这是个好习惯。 我已经阅读并阅读了以下问题：为什么异常通常在类名中带有后缀异常 问题是针对PHP，而响应可能对Java有效。还有其他论点吗？或者真的和区分它们一样简单吗？ 如果我们从上一个问题中选取示例，那么java中是否确实存在名称FileNoFound并非例外的类？如果可能的话，是否应该加上后缀Exception？ 纵观eclipse的快速层次结构Exception，可以肯定的是，它们中的绝大多数确实有例外后缀，但也有一些例外。javassist是一个库的示例，该库似乎有一些没有后缀的异常-例如BadByteCode，BadHttpRequest等。 BouncyCastle 是另一个lib，但有例外 CompileError 我在Google上搜索的信息也很少。

19 java  naming  exceptions 

我可以看到几篇文章，其中强调了在中心位置或过程边界处处理异常的重要性，这是一种好的做法，而不是乱丢try / catch周围的每个代码块。我坚信我们大多数人都了解它的重要性，但是我仍然看到人们仍然使用catch-log-threrow反模式，主要是因为在任何异常情况下，为了简化故障排除工作，他们想记录更多特定于上下文的信息（例如：方法参数）通过），方法是将方法包装在try / catch / log / rethrow周围。 public static bool DoOperation(int num1, int num2) { try { /* do some work with num1 and num2 */ } catch (Exception ex) { logger.log("error occured while number 1 = {num1} and number 2 = {num2}"); throw; } } 在保持异常处理良好实践的同时，有没有正确的方法来实现这一目标？我听说过类似PostSharp的AOP框架，但是想知道这些AOP框架是否有任何不利或主要的性能成本。 谢谢！

19 c#  exceptions  patterns-and-practices  logging 

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

18 bug  debugging  issue-tracking  exceptions  exception-handling 

我正在做单元测试。 我正在尝试测试一个功能。 我从测试组件中调用它。但是，我想，如果远程功能不能处理异常，那么我的测试器组件也将获得异常。 那么我应该担心在测试器组件中出现异常吗？ 谢谢。 编辑： PS： 抛出错误是件好事，但仅对其他功能有用，直到最后一个选择才对最终用户有效！ 天哪，我写了一个编程报价！

18 testing  unit-testing  exceptions 

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

17 java  scala  exceptions  exception-handling 

不久之前，我开始使用Scala而不是Java。对我来说，在这些语言之间进行“转换”过程的一部分是学习使用Eithers而不是（checked）Exceptions。我已经用这种方式编码了一段时间，但是最近我开始怀疑这是否真的是更好的方法。 一个主要的优点Either拥有Exception更好的性能; 一个Exception需要建立一个堆栈跟踪和被抛出。据我了解，虽然Exception不是必须的，但构建堆栈跟踪是必需的。 但随后，人们总是可以构建/继承Exceptions的scala.util.control.NoStackTrace，更是这样，我看到很多的情况下，其中的左侧Either实际上是一个Exception（免收性能提升）。 另一个优点Either是编译器安全。Scala编译器不会抱怨未处理Exception的（不同于Java的编译器）。但是，如果我没记错的话，那么这个决定就是用与本主题中讨论的相同的推理来推理的，所以... 在语法方面，我觉得Exception-style更清晰。检查以下代码块（均实现相同的功能）： Either 样式： def compute(): Either[String, Int] = { val aEither: Either[String, String] = if (someCondition) Right("good") else Left("bad") val bEithers: Iterable[Either[String, Int]] = someSeq.map { item => if (someCondition(item)) Right(item.toInt) else Left("bad") } for { a <- aEither.right bs <- reduce(bEithers).right ignore <- validate(bs).right …

17 coding-style  exceptions  scala  either 

isocpp.org例外常见问题解答指出 不要使用throw来指示函数使用中的编码错误。使用断言或其他机制将流程发送到调试器中或使流程崩溃并收集崩溃转储供开发人员调试。 另一方面，标准库定义了std :: logic_error及其所有派生类，在我看来，它们似乎还应该处理编程错误。是否将空字符串传递给std :: stof（将抛出invalid_argument）不是编程错误？是否将包含不同于'1'/'0'字符的字符串传递给std :: bitset（将抛出invalid_argument）不是编程错误？使用无效索引调用std :: bitset :: set（会抛出out_of_range）不是编程错误吗？如果不是，那么将要测试的编程错误是什么？基于字符串的std :: bitset构造函数仅自C ++ 11起存在，因此在设计时应考虑惯用异常。另一方面，有人告诉我，从根本上不应该使用逻辑错误。 经常出现异常的另一个规则是“仅在特殊情况下使用异常”。但是，库函数应该如何知道哪些情况例外？对于某些程序，无法打开文件可能是一种例外。对于其他人，无法分配内存可能不是例外。中间有100多个案例。无法创建套接字？无法连接或将数据写入套接字或文件？无法解析输入？可能是例外，可能不是。该函数本身肯定通常不知道，它不知道在哪种上下文中调用它。 因此，我应该如何决定是否应为特定功能使用异常？在我看来，实际上唯一一致的方法是将其用于所有错误处理，或一无所有。而且，如果我使用的是标准库，那么该选择就是我自己做的。

16 design  c++  exceptions 

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

16 exceptions  exception-handling 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 3年前关闭。 假设我有一个MediaPlayer类，该类具有play（）和stop（）方法。如果以前没有调用过play方法，则在实现stop方法时使用的最佳策略是什么。我看到两个选项：由于播放器未处于适当状态而引发异常，或无提示地忽略对​​stop方法的调用。 当在某些情况下不应该调用某个方法但该方法的执行对程序总体无害时，一般规则应该是什么？

16 exceptions  methods  state 

我花了几个月的时间来构建应用程序，然后才发现出现了一种模式： logger.error(ERROR_MSG); throw new Exception(ERROR_MSG); 或者，在捕捉时： try { // ...block that can throw something } catch (Exception e) { logger.error(ERROR_MSG, e); throw new MyException(ERROR_MSG, e); } 因此，无论何时我抛出或捕获异常，都将其记录下来。实际上，这几乎是我在应用程序上所做的所有日志记录（除了一些用于应用程序初始化的操作）。 因此，作为一名程序员，我避免重复。因此，我决定将logger调用移至异常构造，因此，每当构建异常时，都会记录事件。当然，我也可以创建一个ExceptionHelper来为我抛出异常，但是这会使我的代码更难以解释，更糟糕的是，编译器无法很好地处理它，而没有意识到对该成员的调用会立即扔。 那么，这是一种反模式吗？如果是这样，为什么？

15 exceptions  logging 

在设计我的第一个“严肃的” C ++库时，我在问自己： 从中衍生出某些例外std::exception是后代吗？ 即使阅读后 设计异常类 为我的图书馆实施的“异常数量”是多少？ 我还不确定。因为，除了常见的（但可能不是很好）的做法之外，我将以库用户的身份假设，std::exception仅当标准库函数在库实现中失败时，库函数才会抛出s，而它对此无能为力。但仍然，在编写应用程序代码时，对我来说非常方便，并且恕我直言，好看的只是抛出一个std::runtime_error。另外，我的用户还可以依赖定义的最小接口，例如what()或代码。 例如，我的用户提供了错误的参数，比抛出a更方便std::invalid_argument吗？因此，与在其他代码中看到的std :: exception的常用用法结合在一起：为什么不走得更远，从您的自定义异常类（例如lib_foo_exception）以及std::exception。 有什么想法吗？

15 c++  exceptions 

从MSDN引用有关StackOverflowException的信息： 当执行堆栈溢出时引发的异常，因为它包含太多的嵌套方法调用。 Too many这里很模糊。我怎么知道什么时候真的太多了？数千个函数调用？百万？我认为它必须以某种方式与计算机中的内存量相关联，但是是否可以提出一个大致准确的数量级？ 我对此很担心，因为我正在开发一个涉及大量使用递归结构和递归函数调用的项目。我不希望我的应用程序在开始用于多个小型测试时会失败。

15 .net  exceptions  recursion  stackoverflow 

抛出NotImplementedException尚未编写的代码是否被认为是不好的做法？可能TODO评论会被认为更安全吗？

15 .net  comments  coding  exceptions 

我正在重构一个相当大的Web应用程序。主要问题之一是不一致的错误处理，我正在尝试提出一个明智的策略。我已经通过set_error_handler创建了一个自定义错误处理程序，该处理程序从本质上转变了ErrorExceptions中的 PHP错误以及一个直接从Exception继承的自定义基本异常类。 在生产环境中，我正在通过set_exception_handler使用通用异常捕获功能，并且将要添加异常记录*的功能。我的难题是在基本异常类或全部捕获中执行实际日志记录的位置。 我想到了将其记录在全部功能中的几个原因： 代码中有很多异常需要转换为基本异常类的适当子代。在此之前，并非所有异常都会被记录。 总括而言，以某种方式感到更自然，基本异常类不应该仅仅这样做。（这可能是一个单一的责任原则，但可能只是一种误导） 以及登录基本异常类的原因之一： 目前，全部收集仅用于生产。将其引入我们的其他环境（开发，测试）很容易，但是这需要进行一些调整，因为错误在每个环境中的处理方式不同，在生产中将其转换为404/503错误页面。 在哪里记录异常有可接受的做法吗？ *日志记录将首先涉及写入文本文件，并且可能会演变成发送某些类型异常的邮件。 @unholysampler的回答提示了一些说明： 我面对的是2 * 10 ^ 6 sloc代码库，其中包含许多我无法控制的第三方内容，而我确实有一些代码可以控制PHP中的preddates异常。而且还有一些糟糕的最新代码，我们正从长期的沉重压力中恢复过来，在这些压力下，我们实际上不得不停止思考并被黑了。 我们正在积极进行重构以解决所有不一致问题，并引入明智的错误处理方法，但这将需要一些时间。在达到正确处理错误的程度之前，我对该怎么办更感兴趣。在某个时候，我可能会问另一个关于明智的例外策略的问题。 记录背后的主要动机是，每当生产中发生任何问题时，都会在我的手机上收到一封电子邮件。我不在乎数据转储是否会很大，如果确实如此，我将有一份cron作业，不时地删除旧的。

15 php  exceptions  logging