probe-rs / vscode

VSCode debug extension for probe-rs. It uses the MS DAP protocol to communicate directly with the probe (via probe-rs), and supports basic command line debugging in addition to VSCode UI.
https://probe.rs/
Other
65 stars 6 forks source link

Panic from probe-rs-debugger are eaten #14

Closed jacobrosenthal closed 2 years ago

jacobrosenthal commented 2 years ago

For instance, it looks like jlink doesnt like speed": 24000"

But was silently not working. When I turned on Debug logging I found the panic

Presumably can watch for the error code of probe-rs-debugger and if its non 0 report and elevate it to error level?

[2021-10-28T21:53:54Z DEBUG probe_rs::probe::jlink] Supported speeds: SpeedInfo { base_freq: 10000000, min_div: 10 }
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: UnsupportedSpeed(24000)', debugger/src/debugger.rs:297:58
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
noppej commented 2 years ago

@jacobrosenthal I agree that the VSCode extension should catch these errors and suspect I can make that change relatively easily. This will be especially useful for un-catchable errors like the stackoveflow you logged in #15.

On a similar note (and probably more helpful in my opinion), we should work to eliminate all the panics that are catchable, like the unwrap() in this issue.

I am happy to work on both, but won't be able to do so for the next 8 days (I don't currently have access to my personal dev machine). If someone wants to PR a fix to this in the meantime, please DM me and I will be happy to share what I know about how the code base.

jacobrosenthal commented 2 years ago

Can confirm this PR. Jlink with wrong speed now gives an Error log, as well as a popover. Thank you!

Screenshot from 2021-11-15 10-22-09 Screenshot from 2021-11-15 10-21-45

noppej commented 2 years ago

Great news. Thanks for testing :)