-
-
Notifications
You must be signed in to change notification settings - Fork 719
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
Load MiniMagick before use #12754
Merged
Merged
Load MiniMagick before use #12754
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
The alternative is to rescue
StandardError
which may be more robust and agnostic of what kind of problem is arising when processing an image.Usually it's good practice to rescue specific errors. But if an unknown error breaks the shop page instead of not displaying an image then that's a bad consequence in production as well.
I want to merge this pull request today to include it in the release. But let's discuss other options, @openfoodfoundation/developers.
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.
I agree that using specific errors for rescuing should be the practice, however, I think it should be the case where we want to handle different errors differently.
If we need to handle each error similarly, then the
StandardError
rescue seems better with some logging or non-code-breaking alerts. In this case, we are rescuing from 3 different errors I guess, but each is handled in a same way. We could shorten this by just rescuingStandardError
. In image processing, many cases may break the code and we may again face a similar issue in the future. That may have been handled by theMiniMagick::Error
rescue. But yes, like you saidStandardError
may be more agnostic to handling these image processing cases.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.
I agree it's worth breaking our rule of "always rescue specific errors" for this case. We are still notifying to Bugsnag so it won't be hiding any new types of errors.
Do we need to differentiate between known errors (ActiveStorage::Error, MiniMagick::Error, ActionView::Template::Error) and new error types?
I think not. Whatever the error type, if it happens infrequently we can probably ignore it. If it is impacting on users and they report it, we can investigate. Or if we see a huge spike in bugsnag, we can investigate it.
So I'm happy to switch to just StandardError. But I would suggest we use at least one of these known error types in the spec (if not already).