eclipse-jdt / eclipse.jdt.debug

Eclipse Public License 2.0
16 stars 46 forks source link

Confusing/redundant Exception Breakpoint options #393

Open ewillink opened 6 months ago

ewillink commented 6 months ago

When setting a Java Exception Breakpoint the Add Java Exception Breakpoint dialog offers me both Java 5 and Java 8 entries for UnsupportedOperationException when I'm running Java 17 but with 5, 8 and 11 also installed. Why are both 5 and 8 offered but not 17?

Surely there is no useful difference between the exception catching (pace a compiled binary level sensitivity bug that is hopefully now fixed)?

If there is a difference, please make the difference clear so that users can understand the hazards of an unwise choice. Today I make an almost arbitrary choice.

If not, please offer just the one useful choice (presumably labelled as the running Java 17.)

jukzi commented 6 months ago

don't know if that is possible:

  1. it does matter in which library the breakpoint is added
  2. technically it is possible to use multiple JDK libraries at once

in any case it should show you 17 too. i can not reproduce that this is missng: image

ewillink commented 6 months ago

It's solid for me on: Eclipse SDK

Version: 2023-12 (4.30) Build id: I20231201-0110

image

image

(No idea what the 'bin' JVMs are for / came from.)

While multiple JDK libraries may be technically possible for you, it is surely extremely confusing for ordinary users who want to set a breakpoint on ALL UnsupportedOperationException. If that is not being supported the users need a multi-select JVM sub-dialog.

However I recall a bug a year or two ago where diverse JVM offerings were provided in perhaps the Type Hierarchy and it was agreed that this was unhelpful and wrong. As far as the user is concerned there is a unified JVM (perhaps merged from all active candidates). How many users are sufficiently sure about the binary level of a particular throw context to correctly specify a particular JVM?

iloveeclipse commented 6 months ago

The JRE's shown are these used in projects. If no project uses Java 17, creating a breakpoint in 17 would not work, as there is nothing in Java model for not used 17.

jukzi commented 6 months ago

While multiple JDK libraries may be technically possible for you,

The breakpoint view is not only for a single VM started but for all VMs, each Vm / each project in workspace can naturally have different JDKs

jukzi commented 6 months ago

(No idea what the 'bin' JVMs are for / came from.)

please create a dedicated bug if the autodetected JVMs get wrong names. image

ewillink commented 6 months ago

Ok, so that explains 'no Java 17'. But

'If that is not being supported the users need a multi-select JVM sub-dialog.'

Excessive. The primary selection should offer what the user wants - breakpoint on thrown java.lang.UnsupportedOperationException. If it is really appropriate to distinguish Java levels then add a multi-check selector to the breakpoint properties so that a Java 5 or 8 but not 17 thrown java.lang.UnsupportedOperationException can be configured.