在Java调试器中,如何忽略永远不会通过我的代码的异常 [英] In a Java debugger, how to ignore exceptions never passing through my code

查看:114
本文介绍了在Java调试器中,如何忽略永远不会通过我的代码的异常的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在使用IntelliJ IDEA进行Java开发,但我也对针对其他IDE的答案或调整Java代码的一般概念感兴趣。因为这是我在许多IDE中遗漏的一个功能,所以我不确定在将调试习惯从其他语言转移时是否错过了工作流概念。



让我们在 myapp。* 中编写一些代码,同时使用 somelib中的框架类。* 。典型的堆栈跟踪可以在任一包中启动,并且可以在它们之间切换多次。假设我的代码中存在错误,并且库代码中没有任何错误,我们也假定我正在进行调试。一个示例堆栈跟踪(仅显示类名称):

  somelib.D(当前堆栈帧)
somelib.C
myapp.Y
myapp.X
somelib.B
somelib.A

通常情况下,我对以下类型的异常不感兴趣,并且不希望调试器对其进行破坏:




  • somelib.B 中抛出,并在 somelib.A 中捕获。库代码是抛出异常来处理库中的问题状态或停止应用程序。在后一种情况下,我只对异常消息感兴趣,希望告诉我有什么问题。


  • 抛出 somelib.D 并抓到 somelib.C 。库代码可以将异常作为一种逻辑形式,其中尝试某些操作,并且在出现问题的情况下采用替代路由,或者通过其他方式(例如,在适当的情况下返回空引用)来通知我的代码) 。




我感兴趣的例外类型:




  • 抛出 somelib.C somelib.D 并没有被抓住somelib.C 或 somelib.D 。在这里,我希望调试器在 myapp.Y 中的行中断,其中我从 somelib.C 中调用代码。


  • 抛出 myapp.X myapp.Y ,被捕获或未被捕获。在这里我希望调试器在线上突破异常。




IntelliJ IDEA给了我选择的选项我想要在捕获或未捕获的异常或两者之间中断,并将异常抛出的位置限制在一组类中。这些选项并没有太多的帮助,因为我通常希望打破任何异常,被捕获或未被捕获,只要我写的代码是在它被抛出的地方和它被捕获的地方之间。,最终

解决方案

似乎不可能以一种方便的方式完成我想要的工作。在这个问题的时候,我正在学习Java并向我的同学教授它,所以一个简单的解决方案将是有利的。



但是我目前使用以下方法的经验似乎是合理的:


  1. catch(Trowable t)围绕每个线程主体,即顶层 Runnable.run() static main(String [])并将这些未捕获异常记录到控制台。

    • 需要注意的是,不要意外捕获这些全部处理程序的检查异常,而是将其作为程序逻辑的一部分来处理。


  2. 开始调试时,不要创建任何异常断点。

  3. 一旦异常记录到控制台,为它创建一个异常断点,并尝试使其再次抛出。

    • 只有发生未检查的异常(即 RuntimeException 的子类),因为其他异常必须被明确地捕获和处理

    • 由于捕获和处理未经检查的异常通常不是程序逻辑的一部分,因此创建这些异常断点而不会对其抛出的位置产生约束,因此不能捕获任何假阳性。 li>

另一种方法是跳过最后两个步骤,而是创建一个异常断点, code> RuntimeException 。但是,在程序逻辑的一部分中捕获异常的更高更改。


I'm currently using IntelliJ IDEA for Java development, but I'm also interested in answers targeting other IDEs or general concepts for debugging Java code. Because this is a feature I've missed in a number of IDEs, I'm unsure if I've missed a workflow concept when transferring my debug habits from other languages.

Let's say I'm writing some code in myapp.* while using framework classes from somelib.*. A typical stack trace may start in either package and may switch several times between them. Let's also say I'm debugging under the assumption that there are bugs in my code and that there aren't any in the library code. An example stack trace (showing only class names):

somelib.D (current stack frame)
somelib.C
myapp.Y
myapp.X
somelib.B
somelib.A

Normally, I'm not interested in the following types of exceptions and do not want the debugger to break on them:

  • Thrown in somelib.B and caught in somelib.A. Either the library code is throwing exceptions to handle problematic state inside the library or to stop the application. In the latter case, I'm only interested in the exception message which hopefully tells me what's wrong.

  • Thrown in somelib.D and caught in somelib.C. The library code may use exceptions as a form of logic where a certain action is tried and an alternative route is taken in the case of a problem or where my code is notified by the problem by other means (e.g. returning a null reference where appropriate).

Types of exceptions I am interested in:

  • Thrown in somelib.C or somelib.D and not caught in somelib.C or somelib.D. Here I want the debugger to break on the line in myapp.Y where I call the code from somelib.C.

  • Thrown in myapp.X or myapp.Y, either caught or uncaught. Here I want the debugger to break on the line the exception is thrown.

IntelliJ IDEA gives me the options to select wether I want to break on caught or uncaught exceptions, or both and to restrict the location where the exception is thrown to a set of classes. These options don't help much as I normally want to break on any exception, wether caught or uncaught, as long as code I've written is between the place it's thrown and the place it's caught, eventually.

解决方案

It seems to be impossible to do exactly what I wanted in a convenient way. At the time of this question I was in the process of learning Java and teaching it to my fellow students, so a simple solution would have been favorable.

But with my current experience it seems reasonable to use the following approach:

  1. Put catch (Trowable t) around each thread body, i.e. at the top level of Runnable.run() and static main(String[]) and log these "uncaught" exceptions to the console.
    • Care needs to be taken to not accidentally catch checked exceptions with these "catch-all" handlers, but to handle them as part of program logic.
  2. When starting to debug, do not create any exception breakpoints.
  3. As soon as an exception is logged to the console, create an exception breakpoint for it and try to make it get thrown again.
    • This should only happen unchecked exceptions (i.e. subclasses of RuntimeException) as other exceptions have to be explicitly caught and handled anyway.
    • As catching and handling unchecked exceptions normally isn't part of a program's logic, creating these exception breakpoints without constraints on the place it's thrown should not catch any "false positives".

An alternative is to skip the last two steps and instead create an exception breakpoint for RuntimeException. But this has a higher change of catching exceptions that are caught as part of the program logic.

这篇关于在Java调试器中,如何忽略永远不会通过我的代码的异常的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆