-
Notifications
You must be signed in to change notification settings - Fork 684
Summary: Add ExecutorchRuntimeException: Throw relevant exceptions from JNI layer in the event of errors #13526
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
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/13526
Note: Links to docs will display an error until the docs builds have been completed. ❌ 3 New FailuresAs of commit e9cf866 with merge base 6e520e2 ( NEW FAILURES - The following jobs have failed:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
This PR needs a
|
4f0f4d2
to
bc8f701
Compare
extension/android/jni/BUCK
Outdated
non_fbcode_target(_kind = fb_android_cxx_library, | ||
name = "executorch_jni", | ||
srcs = ["jni_layer.cpp", "log.cpp", "jni_layer_runtime.cpp"], | ||
srcs = ["jni_layer.cpp", "log.cpp", "jni_layer_runtime.cpp", "jni_helper.cpp"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you refactor these srcs into a list that can be shared across the libs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
f48dd0c
to
5409ecd
Compare
Android Jni layer Test Plan: Tested executorch.jar with executorch demo example and llama demo app Reviewers: Subscribers: Tasks: Tags:
5409ecd
to
e9cf866
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, looks great to me. Thanks for taking this. The only thing I wanted to get your thoughts on is whether we should update the Java definition in Module.java to indicate that it throws. I'm not as familiar with some of the Java conventions, but I believe we can add a checked exception specification to the Java declarations of the JNI methods to indicate that they can throw an ExecutorchRuntimeException.
From what I've seen, opinion seems to be divided on checked exceptions. I don't have a strong opinion either way, and it would potentially require some synchronous code changes to land internally. The advantage might be that it's more clear in the signature that various methods (Module.load / execute) can throw an ExecutorchRuntimeException.
|
||
jni_helper::throwExecutorchException( | ||
static_cast<uint32_t>( | ||
Error::InvalidArgument), // For backward compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From looking at user code, I'm a bit less worried about about strict BC here, so I think you could use the actual error code and not worry about matching the existing exception type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, it is always better to throw the exception with native error code as-is. I wasn't sure 100% abt it, but since you checked the client code, I will make the change
You're probably already be planning this, but could you add/modify an integration test to cover thrown exceptions? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Talked a bit with Sid offline. Sounds like unchecked exceptions are the better option here, which is good with me.
If the native side (JNI C++ code) throws a RuntimeException or IllegalArgumentException (which is what we are doing now), these are unchecked exceptions in Java afaik.
|
Yes was planning on a follow up change |
…om JNI layer in the event of errors (pytorch#13526) Add ExecutorchRuntimeException Test Plan: Tested with executorch-examples and llama android demo. Reviewers: Subscribers: Tasks: Tags: ### Summary [PLEASE REMOVE] See [CONTRIBUTING.md's Pull Requests](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#pull-requests) for ExecuTorch PR guidelines. [PLEASE REMOVE] If this PR closes an issue, please add a `Fixes #<issue-id>` line. [PLEASE REMOVE] If this PR introduces a fix or feature that should be the upcoming release notes, please add a "Release notes: <area>" label. For a list of available release notes labels, check out [CONTRIBUTING.md's Pull Requests](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#pull-requests). ### Test plan [PLEASE REMOVE] How did you test this PR? Please write down any manual commands you used and note down tests that you have written if applicable. Co-authored-by: Github Executorch <github_executorch@arm.com>
…om JNI layer in the event of errors (pytorch#13526) Summary: Add ExecutorchRuntimeException Reviewed By: jackzhxng Differential Revision: D81076817
Add ExecutorchRuntimeException
Test Plan: Tested with executorch-examples and llama android demo.
Reviewers:
Subscribers:
Tasks:
Tags:
Summary
[PLEASE REMOVE] See CONTRIBUTING.md's Pull Requests for ExecuTorch PR guidelines.
[PLEASE REMOVE] If this PR closes an issue, please add a
Fixes #<issue-id>
line.[PLEASE REMOVE] If this PR introduces a fix or feature that should be the upcoming release notes, please add a "Release notes: " label. For a list of available release notes labels, check out CONTRIBUTING.md's Pull Requests.
Test plan
[PLEASE REMOVE] How did you test this PR? Please write down any manual commands you used and note down tests that you have written if applicable.