Filter exceptions when using caught or uncaught exceptions debug filters

[meshake]

The debugger seems to work fine if I uncheck "Caught Exceptions" in the "Breakpoints" pane. However, if I enable it then the debugger breaks in URLClassLoader java class method findClass line 382:

Exception has occurred: java.lang.ClassNotFoundException
"java.lang.ClassNotFoundException: example.Hello"

To Reproduce
Steps to reproduce the behavior:

1. Create Hello.scala file with the following code:

package example

object Hello {
  def main(args: Array[String]): Unit = {
    val a = "Hello World!"
    val b = 42
    println(a)
  }
}

2. Add a breakpoint on "val b = 42"
3. Enable "Caught Exceptions" in the "Breakpoints" pane.
4. Click "Debug"
5. Observe breaking on exception thrown from URLClassLoader.findClass

Expected behavior

I would expect that the ClassNotFoundException exception is not thrown.

Screenshots

Without "Caught Exceptions" enabled:

With "Caught Exceptions" enabled:

Installation:

• Operating system: Windows 10
• VSCode version: 1.44.2
• Metals version: 0.8.4

Search terms

Debugger

[tgodzik]

Thanks for reporting, I can't seem to reproduce it currently. Might be a Windows specific issue or maybe JDK one? What Java version are you using?

[meshake]

@tgodzik

java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b04, mixed mode)

[tgodzik]

Thanks! @alekseiAlefirov managed to confirm the issue, this seems to be happening on JDK 8 and looks fine on JDK 11

[tgodzik]

I finally managed to investigate this a bit and it seems that because we are currently using https://github.com/microsoft/java-debug it breaks on each thrown exception and the current the behavior is expected. There is unfotunately no way to specify an exact filter using DAP. We would most likely need to solve the issue in Metals, my guess is that we would need to:

1. When stopped event is fired on an exception we don't send the message to the client.
2. We ask about the specific exception that was thrown.
3. If that exception is allowed according to out filter (most likely new user setting or debug one), we then forward the stopped event, otherwise we send the continue event.

I am not sure if that is a perfect solution, I think it would be much better if it was solved on the client side.

Java extension did something similar here: microsoft/vscode-java-debug#829

As this is a bit more involved than initially though I will move it out to feature requests.

[vishalovercome]

This issue becomes one major source of frustration when working with heavy weight frameworks such as flink, kafka. While these frameworks handle exceptions we still have to sift through them to get to our own code. Only recourse is to liberally add breakpoints and hope to catch them soon. I'm not sure if VSCode's logpoints work as then I would simply add those liberally and examine all outputs in one go

[adpi2]

Filtering debug steps is something I have investigated in scalacenter/scala-debug-adapter#122. I think we can solve it in the debug server by adding a notion of ClassFilters into java-debug as proposed in scalacenter/scala-debug-adapter#122 as "Solution 1". My plan is to start working on it in April.