Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing/redundant Exception Breakpoint options #393

Open
ewillink opened this issue Feb 16, 2024 · 6 comments
Open

Confusing/redundant Exception Breakpoint options #393

ewillink opened this issue Feb 16, 2024 · 6 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@ewillink
Copy link

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 jukzi added bug Something isn't working help wanted Extra attention is needed labels Feb 16, 2024
@jukzi
Copy link
Contributor

jukzi commented Feb 16, 2024

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
Copy link
Author

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
Copy link
Member

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
Copy link
Contributor

jukzi commented Feb 16, 2024

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
Copy link
Contributor

jukzi commented Feb 16, 2024

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

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

@ewillink
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants