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

Error::description() deprecated, should use Display trait #25

Open
Skaldebane opened this issue Mar 24, 2023 · 9 comments
Open

Error::description() deprecated, should use Display trait #25

Skaldebane opened this issue Mar 24, 2023 · 9 comments

Comments

@Skaldebane
Copy link

Hi there! I just started using your library, and it worked perfectly well the first time I used it (2 days ago). The IDE was complaining about description() being deprecated, but it was only a warning and everything was working perfectly.

However now I'm getting a RuntimeException in Java whenever I try to call my JNI function, with the following message:

java.lang.RuntimeException: JNI call error!. Cause: description() is deprecated; use Display

This is quite confusing, because why on earth is this compile-time check inside the generated shared library file itself?! I couldn't really figure out what's causing this.

My only hypothesis for now is that the Error::description() function is automatically populated with that message to get the attention of developers to use Display instead, which makes it useless to understand what's going on under-the-hood.

@Skaldebane
Copy link
Author

I checked the source code for Error in the standard lib, and yeah, description() is indeed hardcoded to that string.

From error.rs:

image

@Skaldebane
Copy link
Author

It's been buried for a while: rust-lang/rfcs#2230

@Skaldebane Skaldebane changed the title Error::description() deprecated, should use Display trait (causes Runtime exception?!) Error::description() deprecated, should use Display trait Mar 24, 2023
@giovanniberti
Copy link
Owner

Thank you for the issue! I'll try to fix it ASAP as it seems it impacts already other users #29

@Skaldebane
Copy link
Author

Skaldebane commented Jun 16, 2023

I guess a recent version of Rust just shot that function off of std, since it's been deprecated for long enough :p

But yeah, using Display will make errors actually print something useful to make debugging easier, since description was made useless for quite some time now with the hardcoded message.

P.S.: Thanks a lot for this incredible crate! It makes JNI interop a breeze, alongside cargo-ndk which makes building for Android (with NDK) an easy one-line command!

@Skaldebane
Copy link
Author

Hi! Any updates on this?

@EliseChouleur
Copy link
Collaborator

EliseChouleur commented Sep 26, 2023

Hi !
Could you check with darling update ? #31

@Skaldebane
Copy link
Author

Skaldebane commented Sep 26, 2023

@EliseChouleur assuming you're asking me, it may take me some time, but I'll give the PR a shot on Android and desktop and reply with the results!

@Skaldebane
Copy link
Author

Skaldebane commented Nov 24, 2023

Hi again! Sorry for my delay, but I can confirm that #31 fixes the issue on Android.

Now instead of the confusing:
java.lang.RuntimeException: JNI call error!. Cause: description() is deprecated; use Display
it correctly reports the error message
java.lang.RuntimeException: JNI call error!. Cause: Java exception was thrown

So updating darling is a valid fix. I don't expect there to be any difference on the desktop (JVM) side, since this bug is purely from the Rust side.

@Skaldebane
Copy link
Author

This makes me wonder, however, that it should be possible to pass a custom message to JniError::JavaException type, so that error messages are generally more helpful.

For example in this case, if I want information about the cause of the error, I'd have to log it right before returning the JniError::JavaException to keep those details.

However this should be its own issue.

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 a pull request may close this issue.

3 participants