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

Throw JS exception instead of Java wrapping object #23

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

zbynek
Copy link
Contributor

@zbynek zbynek commented Dec 2, 2024

Fixes #20

Copy link
Member

@niloc132 niloc132 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, are you sure about this? Can you put together a quick test that confirms this?

I'm asking because this is pretty nearly (but not exactly) what GWT's own Impl.reportToBrowser does in a case like this, directly throw the throwable instance, right? The Throwable overload first unwraps any JavaScriptException to find the underlying object that was thrown from plain JS, but if it was a "real" Java exception it is just thrown directly. That is, it doesn't unwrap "real" exceptions to the backing object.

Is #20 specifically about native exceptions? If so, we might have a hard time making that work as expected in both GWT and J2CL.

ThrowableTestBase has some handy methods to verify the various important cases, might be worth stealing bits of it here.

@zbynek
Copy link
Contributor Author

zbynek commented Dec 3, 2024

Before this change I was getting this in the console:
image
Now I get the stacktrace I'd expect.

@zbynek
Copy link
Contributor Author

zbynek commented Dec 6, 2024

.reportToBrowser does in a case like this, directly throw the throwable instance, right?

By the time exceptions reach window.onerror, they are

  • unwrapped if actually not caught (both native and Java exceptions)
  • unwrapped if caught and reported by GWT 2's Scheduler (native)
  • wrapped if caught and reported by GWT 2's Scheduler (Java exceptions)
  • wrapped if caught and reported by gwt-core's Scheduler (both native and Java)

I guess replicating GWT 2's scheduler is hard, but why not always unwrap (as this PR does)?

@niloc132
Copy link
Member

Mostly I'm hoping for unit tests here so we can validate those with any patch - and see if we can find a simpler way to achieve the desired effect.

Specifics are going to be slightly different from JSNI to jsinterop as jsni strongly encouraged the use of $entry (which was part of Impl.java). They also may vary slightly between GWT and J2CL generated exceptions.

@zbynek
Copy link
Contributor Author

zbynek commented Dec 11, 2024

The functionality changed here is similar to the stuff tested in https://github.com/gwtproject/gwt/blob/c2229e7557450cd2842269f5fe9cb8586e90b50c/user/test/com/google/gwt/core/client/WindowOnErrorTest.java#L34 , I'll try to implement a similar test here.

@zbynek
Copy link
Contributor Author

zbynek commented Dec 11, 2024

@niloc132 this is now rebased on #24 -- the other PR makes sure UncaughtExceptionHandler gets at least something when an error is reported. This PR makes sure it's actually the RuntimeException and not a js-wrapper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Errors from scheduler wrapped in Java error in console
2 participants