Questions tagged «exceptions»

我正在阅读“学习Python”，发现了以下内容： 用户定义的异常也可以表示非错误情况。例如，当找到匹配项时，可以对搜索例程进行编码以引发异常，而不是返回状态标志以供调用方解释。在下面，try / except / else异常处理程序执行if / else返回值测试器的工作： class Found(Exception): pass def searcher(): if ...success...: raise Found() # Raise exceptions instead of returning flags else: return 因为Python是动态类型化的，并且是内核的多态形式，所以通常使用异常而不是哨兵返回值来表示这种情况。 我已经在各种论坛上多次讨论过这种问题，并且使用StopIteration结束循环对Python进行了引用，但是在官方样式指南中找不到很多（PEP 8附带提供了一个流程控制异常引用）或开发人员的声明。有没有官方声明这是Python的最佳做法？ 这（作为控制流的异常是否被认为是严重的反模式？如果是，为什么？）也有几个注释者指出此样式是Pythonic。这是基于什么？ TIA

15 python  programming-practices  exceptions 

我总是觉得自己很努力……试图在try / catching和代码之间保持正确的平衡，而这些代码又不会变成令人讨厌的选项卡，方括号和异常，就像火薯一样被扔回到调用堆栈中。例如，我有一个正在开发的使用SQLite的应用程序。我有一个抽象SQLite调用的数据库接口，以及一个接受要进出数据库的事物的模型...因此，如果/当发生SQLite异常时，必须将其扔给模型（被称为模型） ），谁必须将其传递给调用AddRecord / DeleteRecord / whatever ... 我喜欢异常，而不是返回错误代码，因为错误代码可以忽略，遗忘等，而本质上必须处理异常（允许，我可以立即捕获并继续前进...）肯定有比我现在要做的更好的方法。 编辑： 我应该用一些不同的措辞。我知道要重新投掷不同类型的球，我的措辞很差，这是我自己的错。我的问题是……这样做时如何最好地保持代码干净？过了一会儿，它才开始让我感到非常混乱。

15 code-quality  exceptions  readability  clean-code 

我一直都认为属性（即，它们的设置/获取操作）应该快速/立即且无故障。您永远不必尝试/赶上获取或设置属性。 但是我正在研究将某些对象的属性应用基于角色的安全性的一些方法。例如Employee.Salary属性。我尝试过的一些其他解决方案尝试过的解决方案（尤其是此处的AOP示例）涉及到如果访问者没有正确权限的情况下引发异常-但这违反了我的个人规则很长一段时间了。 所以我问：我错了吗？事情变了吗？是否已接受属性应该能够引发异常？

15 .net  exceptions 

具体询问默认构造函数 考虑到构造函数会初始化一个对象的所有数据，如果我创建了一个未经适当初始化就无法使用的类，那么默认构造函数是否就没有用？考虑： // 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 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 多年来，Java的受检查异常受到了一些负面报道。一个明显的迹象是，它实际上是世界上唯一拥有它们的语言（甚至不是其他JVM语言，例如Groovy和Scala）。诸如Spring和Hibernate之类的著名Java库也不使用它们。 我个人已经发现了它们的一种用途（在层之间的业务逻辑中），但除此之外，我还是非常反对检查的异常。 还有其他我没有意识到的用途吗？

14 java  exceptions  errors 

我了解异常如何工作以及如何在C＃中捕获和处理异常，但是我如何模拟可能导致异常的事件以确保正确捕获异常？例如，是否可以在一种可以模拟网络问题，数据库问题等的测试平台上运行应用程序？异常的性质似乎很难重现，因此很难确保您的代码可以应对它们。 尽管我主要使用C＃/。NET / Visual Studio开发，但是与其他语言有关的答案或资源可能会很有用。

14 c#  testing  exceptions 

我有一堆处理值验证的类。例如，一个RangeValidator类检查一个值是否在指定范围内。 每个验证器类都包含两个方法：is_valid(value)，该方法返回True或False取决于值，并ensure_valid(value)检查指定的值，如果值有效，则不执行任何操作，或者，如果值与预定义的规则不匹配，则抛出特定的异常。 当前有两种与此方法关联的单元测试： 传递无效值并确保引发异常的代码。 def test_outside_range(self): with self.assertRaises(demo.ValidationException): demo.RangeValidator(0, 100).ensure_valid(-5) 传递有效值的那个。 def test_in_range(self): demo.RangeValidator(0, 100).ensure_valid(25) 尽管第二项测试已完成工作-如果抛出异常，则失败，如果ensure_valid没有抛出异常，则成功，但assert内部没有s 的事实看起来很奇怪。读过此类代码的人会立即问自己，为什么要进行似乎无所事事的测试。 当测试不返回值且没有副作用的方法时，这是当前的做法吗？还是应该以其他方式重写测试？或者只是发表评论以解释我在做什么？

13 unit-testing  exceptions  readability 

我对异常处理和日志记录的关注并没有多大区别，因为两者都是跨领域的关注。你怎么看？它不应该单独处理而不是与方法实现的核心逻辑交错处理吗？ 编辑：我想说的是，在我看来，方法实现应只包含成功执行路径的逻辑，而异常应在其他地方处理。这与已检查/未检查的异常无关。 例如，一种语言可以通过使用如下结构以完全检查的方式处理异常： class FileReader { public String readFile(String path) { // implement the reading logic, avoid exception handling } } handler FileReader { handle String readFile(String path) { when (IOException joe) { // somehow access the FileInputStram and close it } } } 在上述概念性语言中，程序在没有FileReader 处理程序的情况下将无法编译，因为FileReader 类的readFile不会引发异常。因此，通过声明FileReader 处理程序，编译器可以确保对其进行处理，然后程序可以进行编译。 这样，我们就可以同时处理已检查和未检查的异常问题：健壮性和可读性。

13 design  exceptions  aspect-oriented 

介绍 如果网站或系统上发生错误，则将其记录下来并向用户显示带有错误代码的礼貌消息当然是有用的。 而且，如果您有许多系统，则不希望散布这些信息-最好有一个集中的位置。 在最简单的级别上，所需要做的就是增加ID和错误详细信息的序列化转储。（可能的“集中位置”是电子邮件收件箱。） 另一方面，也许是一个完全规范化的数据库，该数据库还允许您按下按钮并查看每天的错误图，或者确定系统X上最常见的错误类型是服务器A是否拥有更多的数据库。服务器B的连接错误，等等。 我在这里指的是通过远程系统记录代码级错误/异常- 而不是 “基于人的”问题跟踪，例如使用Jira，Trac等进行的跟踪。 问题 我正在寻找使用过这种系统的开发人员的想法，特别是关于以下方面的想法： 您不能没有哪些基本功能？ 真正节省您时间的功能有什么好处？ 哪些功能似乎是个好主意，但实际上没有用吗？ 例如，我想说一个“显示重复项”功能很重要，它可以识别多次出现的错误（而不必担心可能会有所不同的“不重要”细节）。 用于“在[Jira / etc]中为此错误创建问题”的按钮听起来像是节省了时间。 再次重申一下，我所追求的是使用过此类系统的人们的实践经验，最好是对功能令人敬畏/可怕的原因进行备份。 （无论如何，如果要进行理论化，至少要这样标出答案。）

13 exceptions  issue-tracking  errors  logging 

您何时开始编写异常处理代码？您何时开始编写日志记录语句。 出于阐述这个问题的目的，让我们假设我们使用Log4net日志记录在.NET平台上，但是可以以一般方式随意回答。 解决方案：Windows窗体项目。项目：UI，BusinessRules，DataHandlers 因此，您是否打算编写DataHandlers来进行数据处理，例如首先创建，读取，更新，删除。 然后遵循您的业务规则 然后是您的用户界面或以上的任何其他排列。 测试您的应用程序的功能。 而再开始写你的异常处理代码和最后日志记录代码？ 在什么时候开始编写您的异常处理代码？ PS：在书Clean Code中，他们说首先写您try-catch-finally块。那促使我提出这个问题。

13 programming-practices  exceptions  logging 

我有一段代码可以表示为： public class ItemService { public void DeleteItems(IEnumerable<Item> items) { // Save us from possible NullReferenceException below. if(items == null) return; foreach(var item in items) { // For the purpose of this example, lets say I have to iterate over them. // Go to database and delete them. } } …

12 c#  exceptions  error-handling 

首先，我很清楚为什么C ++中没有“最终”构造？但是关于另一个问题的冗长的评论讨论似乎需要一个单独的问题。 除了finally在C＃和Java中每个作用域基本上只能存在一次（== 1）并且单个作用域可以具有多个（== n）C ++析构函数的问题之外，我认为它们本质上是同一件事。（存在一些技术差异。） 但是，另一个用户认为： ...我试图说dtor本质上是（发布语义）的工具，而最终本质上是（提交语义）的工具。如果您不明白为什么，请考虑：为什么在finally块中相互抛出异常是合法的，以及为什么析构函数则不这样？（从某种意义上说，这是数据与控制的事情。析构函数用于释放数据，最终用于释放控制。它们是不同的；不幸的是C ++将它们绑在一起。） 有人可以清理吗？

12 c++  exceptions  finally 

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

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

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

12 programming-practices  books  exceptions  exception-handling 

我有一个接口方法，在文档中指出它将抛出特定类型的异常。该方法的实现使用引发异常的东西。捕获内部异常，并抛出接口协定声明的异常。这是一个可以更好解释的代码示例。它是用PHP编写的，但是遵循起来非常简单。 // in the interface /** * @return This method returns a doohickey to use when you need to foo * @throws DoohickeyDisasterException */ public function getThatDoohickey(); // in the implementation public function getThatDoohickey() { try { $SomethingInTheClass->doSomethingThatThrowsAnException(); } catch (Exception $Exc) { throw new DoohickeyDisasterException('Message about doohickey failure'); } …

12 exceptions  abstraction