Questions tagged «exceptions»

在设计异常时，我应该编写用户或开发人员应该理解的消息吗？谁真正应该是异常消息的阅读者？ 我发现异常消息根本没有用，我总是很难编写它们。按照约定，异常的类型应该已经告诉我们为什么某些事情不起作用，并且自定义属性可能会添加更多信息，例如文件名，索引，键等。那么为什么在消息本身中重复它呢？自动生成的消息也可以执行此操作，它所必须包含的就是带有其他属性列表的异常名称。这和手写文本一样有用。 根本不编写消息，而是使用特殊的异常渲染器来处理可能创建于不同语言中的有意义的消息，而不是用代码对其进行硬编码，这会更好吗？ 我被问到这些问题中的任何一个是否都可以回答我的问题： 如何编写好的异常消息 为什么许多异常消息不包含有用的详细信息？ 我读过他们两个，但对他们的回答感到不满意。他们通常谈论用户，并着重于消息本身的内容，而不是收件人，事实证明，至少可以有两个用户：最终用户和开发人员。我永远不知道在编写异常消息时应该和哪个人说话。 我什至认为这条著名的消息根本没有任何真正的价值，因为它只是用不同的词来重复异常类型的名称，所以为什么还要费心编写它们呢？我可以完美地自动生成它们。 对我而言，异常消息缺乏读者的区分。一个完美的例外将需要提供至少两个消息版本：一个针对最终用户，一个针对开发人员。仅将其称为消息太笼统了。然后，应该用英语编写开发人员消息，但最终用户的消息可能需要翻译成其他语言。仅用一条消息是不可能实现所有这些的，因此异常将需要为最终用户消息提供一些标识符，正如我刚才所说的，该标识符可能以不同的语言提供。 当我阅读所有其他链接的问题时，我得到的印象是，异常消息的确是由最终用户而非开发人员阅读的……一条消息就像也要吃蛋糕一样。

27 design  exceptions 

诸如Fortify之类的静态代码分析器会在一个finally块内抛出异常时说“抱怨” Using a throw statement inside a finally block breaks the logical progression through the try-catch-finally。通常我同意这一点。但是最近我遇到了以下代码： SomeFileWriter writer = null; try { //init the writer //write into the file } catch (...) { //exception handling } finally { if (writer!= null) writer.close(); } 现在，如果writer无法正确关闭，则该writer.close()方法将引发异常。应该抛出异常，因为（很可能是）写入后未保存文件。 我可以声明一个额外的变量，如果关闭时出错，则进行设置，writer并在finally块之后引发异常。但是这段代码可以正常工作，我不确定是否要更改它。 在finally块内引发异常的缺点是什么？

27 coding-style  exceptions  exception-handling 

我经常遇到带有附加布尔参数的方法/函数，该参数控制是否在失败时引发异常或返回null。 已经讨论了在哪种情况下哪种选择是更好的选择，因此在这里我们不要专注于此。参见例如返回魔术值，抛出异常或在失败时返回false？ 相反，让我们假设我们有一个很好的理由要支持这两种方式。 我个人认为这样的方法应该分为两种：一种在失败时引发异常，另一种在失败时返回null。 那么，哪个更好？ 答：一种带$exception_on_failure参数的方法。 /** * @param int $id * @param bool $exception_on_failure * * @return Item|null * The item, or null if not found and $exception_on_failure is false. * @throws NoSuchItemException * Thrown if item not found, and $exception_on_failure is true. */ function loadItem(int $id, bool $exception_on_failure): …

24 exceptions 

每当Perl，Python，C ++或Tcl程序因未处理的异常而暂停时，这些语言运行时都会注意为该过程注册一个非零的退出代码。如果基于Eclipse的程序在启动过程中失败，则它们也会返回1。java.exe但是，由标准运行的程序无论终止多么突然，都会很高兴地返回零，除非程序System.exit()使用退出值进行调用。甚至AssertionFailedError或UnsatisfiedLinkError作为成功退出被报告回调用程序。 当然，并非所有系统都具有程序返回码，但是Unix和Windows非常重要，足以保证java.lang.Process.exitValue()子进程的运行。他们还不保证为父流程遵守约定吗？ 这是语言设计上的缺陷还是仅仅是实现上的缺陷？是否有争论说这是个好主意？

24 java  exceptions 

一些编程语言（例如Scala）具有Option类型（也称为Maybe）的概念，可以包含值也可以不包含值。 根据我对它们的了解，与相比null，它们被广泛认为是处理此问题的一种更好的方法，因为它们明确地迫使程序员考虑可能没有值的情况，而不仅仅是在运行时崩溃。 另一方面，Java中的Checked Exception似乎被认为是一个坏主意，Java似乎是实现它们的唯一被广泛使用的语言。但是它们背后的想法似乎与该Option类型有些相似，以明确地迫使程序员处理可能引发异常的事实。 Option类型所没有的Checked Exception还有其他问题吗？还是这些想法与我想的不一样，并且有充分的理由强制对Option而不是对Exception进行显式处理？

23 exceptions 

我正在构建一个API，一个上传文件的函数。如果文件上传正确，此函数将不返回任何内容/无效，并且在出现问题时将引发异常。 为什么要例外而不是错误？因为在异常中，我可以指定失败的原因（无连接，文件名丢失，密码错误，文件描述丢失等）。我想构建一个自定义异常（带有一些枚举来帮助API用户处理所有错误）。 这是一个好习惯还是返回一个对象（内部包含布尔值，可选错误消息和错误枚举）更好？

22 java  api-design  exceptions  functions  architectural-patterns 

异常和异常处理来自何处？ 我喜欢.NET使用它的方式，喜欢C ++支持它的方式（但是不幸的是，库使用返回代码或用C编写）。我知道它在所有新语言中的标准都是多少，但是谁首先设计了它，或者它是从哪里来的呢？ C ++是使用它的第一语言吗？我不知道其他年龄更大的人。

22 history  exceptions 

阅读Eric Lippert 关于异常的文章绝对是我应该以生产者和消费者的方式处理异常问题的开阔视野。但是，我仍在努力制定有关如何避免引发令人讨厌的异常的准则。 特别： 假设您有一个Save方法可能会失败，因为a）有人在您之前修改了该记录，或者b）您要创建的值已经存在。这些条件是预料之中的，并非例外，因此，您不会抛出异常，而是决定创建方法的Try版本TrySave，该方法返回一个布尔值，指示保存是否成功。但是，如果失败了，消费者将如何知道问题出在哪里呢？还是最好返回一个表示结果的枚举，例如Ok / RecordAlreadyModified / ValueAlreadyExists？使用integer.TryParse时不存在此问题，因为该方法失败的原因只有一个。 前面的例子真的令人烦恼吗？还是在这种情况下抛出异常是首选方式？我知道大多数库和框架（包括Entity框架）都是这样做的。 您如何决定何时创建方法的Try版本，以及如何提供某种方法进行事前测试的方法？我目前正在遵循以下准则： 如果有可能发生竞争，请创建一个Try版本。这避免了消费者需要捕获外部异常。例如，在前面描述的Save方法中。 如果测试条件的方法几乎可以完成原始方法的所有工作，则创建一个Try版本。例如，integer.TryParse（）。 在任何其他情况下，请创建一种测试条件的方法。

21 exceptions 

我不太了解某些编程语言人员对null引用的一致抨击。他们有什么不好？如果我请求对不存在的文件进行读取访问，那么我很高兴得到异常或空引用，但是异常被认为是好的，但空引用被认为是坏的。这背后的原因是什么？

21 programming-languages  exceptions  null 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 您如何向程序员讲授异常处理。轻松教授所有其他内容-数据结构，ASP.NET，WinForms，WPF，WCF-您可以轻松地讲授所有内容。 使用异常处理，最终对它们进行尝试尝试只是异常处理的语法性质。 但是，应该教的是-您将代码的哪一部分放在try块中？你在赶路区做什么？ 让我用一个例子来说明。 您正在处理Windows Forms Project（一个小型​​实用程序），并且已按照以下3个不同的项目进行了设计。 UILayer 业务层 数据层 如果在DataLayer上引发了异常（让我们说加载XDocument会引发异常）（UILayer调用BusinessLayer，而BusinessLayer依次调用DataLayer），您是否只需执行以下操作 //In DataLayer try { XDocument xd_XmlDocument = XDocument.Load("systems.xml"); } catch(Exception ex) { throw ex; } 哪些再次在BusinessLayer中引发，哪些在UILayer中捕获，在那里我将其写入日志文件？ 这是您进行异常处理的方式吗？

21 java  programming-practices  c#  teaching  exceptions 

应该使用catch块来编写逻辑，即处理流控制等吗？还是仅仅为了抛出异常？它会影响代码的效率或可维护性吗？ 在catch块中写逻辑有什么副作用（如果有）？ 编辑： 我见过一个Java SDK类，其中他们在catch块内编写了逻辑。例如（摘录自java.lang.Integer课堂）： try { result = Integer.valueOf(nm.substring(index), radix); result = negative ? new Integer(-result.intValue()) : result; } catch (NumberFormatException e) { String constant = negative ? new String("-" + nm.substring(index)) : nm.substring(index); result = Integer.valueOf(constant, radix); } 编辑2： 我正在阅读一个教程，他们将其视为在异常内编写例外情况逻辑的优势： 异常使您能够编写代码的主要流程，并处理其他地方的特殊情况。 有什么具体准则，何时在catch块中编写逻辑，何时不编写逻辑？

21 java  programming-practices  exceptions 

那个设定 我经常很难确定何时以及如何使用异常。让我们考虑一个简单的示例：假设我正在抓取一个网页，说“ http://www.abevigoda.com/ ”，以确定Abe Vigoda是否还活着。为此，我们要做的就是下载页面并寻找出现“ Abe Vigoda”短语的时间。我们返回首次亮相，因为其中包括安倍晋三的身份。从概念上讲，它将如下所示： def get_abe_status(url): # download the page page = download_page(url) # get all mentions of Abe Vigoda hits = page.find_all_mentions("Abe Vigoda") # parse the first hit for his status status = parse_abe_status(hits[0]) # he's either alive or dead return status == "alive" where parse_abe_status(s)以“ …

20 python  exceptions 

我一直想知道应该为软件的各个部分实现并抛出多少个不同的异常类。我的特定开发通常与C ++ / C＃/ Java有关，但是我认为这是所有语言的问题。 我想了解抛出很多不同异常的情况，以及开发人员社区对好的库的期望。 我看到的权衡包括： 更多的异常类可以为API用户提供非常精细的错误处理级别（容易发生用户配置或数据错误，或者找不到文件） 更多的异常类允许将特定于错误的信息嵌入到异常中，而不仅仅是字符串消息或错误代码 更多的异常类可能意味着更多的代码维护 更多的异常类可能意味着该API对用户的访问性降低 我希望了解异常用法的场景包括： 在“配置”阶段，可能包括加载文件或设置参数 在“操作”类型阶段，库可能正在运行任务并正在做一些工作，也许在另一个线程中 不使用异常或较少异常（作为比较）的其他错误报告模式可能包括： 更少的异常，但是嵌入了可以用作查找的错误代码 直接从函数返回错误代码和标志（有时无法从线程返回） 发生错误时实施事件或回调系统（避免堆栈展开） 作为开发人员，您希望看到什么？ 如果有很多异常，您是否还要分别处理错误？ 根据操作阶段，您是否倾向于错误处理类型？

20 design-patterns  exceptions 

我刚刚回顾了一段时间后写的一些代码，可以看到我有几个私有方法，如果方法参数存在问题，它们会抛出argumentsnullexceptions和/或argumentsexceptions。 我想我的理由是，如果将来有人尝试“滥用”该方法，则可以帮助将来证明该应用程序。但是，由于这是一个私有方法，可能调用此方法的人员可以看到相关的注释和代码，因此不必抛出此代码。拥有它们当然不会有任何伤害，尽管确实会增加混乱。 我的感觉是，这些异常通常在将公开公开的API之类的东西上更有用。

20 exceptions 

每当我需要提供有关异常的其他信息时，我都会想知道哪种方法实际上是正确的方法。 为了这个问题，我写了一个例子。假设有一个我们要更新Abbreviation属性的类。从SOLID的角度来看，这可能并不完美，但是即使我们通过具有某些服务的DI 传递了工作方法，也会发生相同的情况-发生异常，并且没有上下文。回到示例... class Person { public int Id { get; set; } public string Name { get; set; } public string Abbreviation { get; set; } } 然后是该类的一些实例和一个调用worker方法的循环。它可以抛出StringTooShortException。 var persons = { new Person { Id = 1, Name = "Fo" }, new Person { Id = 2, Name …

20 c#  exceptions