-
-
You must be signed in to change notification settings -
Surface original error when a selected plugin fails to read file. #7901
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
@psobolewskiPhD what do you think |
Can you copy the complete stack traces to a gist? (I'm curious about what the complete original stack trace is.)
yeah 100% please don't do this — when in Looking at the commit history, are we expecting #7826 to merge first? |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7901 +/- ##
==========================================
+ Coverage 92.91% 92.94% +0.02%
==========================================
Files 641 641
Lines 60615 60628 +13
==========================================
+ Hits 56319 56348 +29
+ Misses 4296 4280 -16 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
@jni the gist is here. You basically have to scroll past two of our
No, I had just branched off that for convenience (but turned out not to be that convenient) and then I was too lazy to go back to main once I'd committed 😆 #7826 will help because there's some stuff that we don't even try to open right now, but they're independent. |
I just tested with an ome-tiff:
I like this! much better! For imageio it still swallows the error though.
So it's the generic
very helpful! So not sure if that's a function of the implementation here a real limitation or related to the other PR. |
Super weird. Looking at our reader file, I believe we just call imageio: napari/napari_builtins/io/_read.py Line 94 in c069270
There's no try/except around it that would swallow things and there's no try except anywhere that would swallow an OSError. (Which btw seems to me to be a very weird error class for this error, but whatever!) Given that the traceback comes from npe2._read:
I suspect that the fix must go there. |
I'll take a look at the imageio case. It's weird because that npe2 error is thrown afaik when the plugin returns a null layer, OR if a plugin isn't tried at all, rather than when it errors. I'll try reproduce, but I'm not sure I can, cause when I try to open mp4s I don't get that same error from image.io |
Ok @psobolewskiPhD I still haven't reproduced that Without #7826, our So:
which is not amazing, but it is better.
|
plugin_name, | ||
paths, | ||
getattr(error, 'original_error', None), |
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.
What is the benefit from adding a message to string inside ReaderPluginError
constructor, instead of here?
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.
when we discussed this we were considering using the error's stack trace rather than just the message, but maybe now this can be reverted @DragaDoncila?
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.
@Czaki in this case we have two "layers" of ReaderPluginError
that we need to surface the original error through i.e. error
here isn't the error we're actually trying to show.
We first raise ReaderPluginError from e
in ViewerModel
and then we raise it here in the GUI handling code. I therefore decided to store an original
error with the ReaderPluginError
so that regardless of whether we catch this error elsewhere or just raise it here, we have easy access to that original non-napari-reading-code error.
I could just concatenate the original error to the error message in ViewerModel
and then "re-concatenate` it here, but this seemed cleaner. Open to suggestions!
References and relevant issues
Discussed in #7826
Description
When a plugin is selected to read a file, but it fails OR when there is only a single plugin available to read a file, we raise our own error message
from
the original error. However, this means the (likely more useful) original error thrown by the plugin doesn't appear unless you scroll up in the stack trace, even if the error would be relatively easy to fix e.g. just installimagecodecs
or something.This PR improves our own error message so that the original error is printed to the user, and they are advised to scroll up to see the full stack trace. @brisvag and I discussed maybe bringing the actual stack trace down, but decided that would be a lot more complex, and potentially confusing for developers who are used to just scrolling up to get to their own code.
Prior to this PR, if you don't have
tifffile
installed (for some reason) and try to open a tiff file:With this PR: