-
Notifications
You must be signed in to change notification settings - Fork 8
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
Log exceptions and fix erroneous handling #46
Log exceptions and fix erroneous handling #46
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #46 +/- ##
===========================================
+ Coverage 52.41% 52.79% +0.38%
===========================================
Files 18 18
Lines 1679 1680 +1
Branches 296 296
===========================================
+ Hits 880 887 +7
+ Misses 749 743 -6
Partials 50 50 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
Why not just reraise the exception?
I dislike changing the exception type and inserting a possibly different one. The only reason we should be catching these in the first place is to write to the logger. Then just raise the same exception again if we aren't handling it. |
Alright, I can work with that. |
@WalterKolczynski-NOAA Alright, I added some logging and re-raising of caught exceptions. |
Description
This fixes a few custom exceptions. Attempting to raise an exception object results in an unintended/misleading error. For instance,
Results in
Instead, the base exception should be casted as a string:
Which returns
In many cases, this is purely redundant as the message will already appear above. Thus, some exceptions were removed entirely or condensed.
Type of change
How Has This Been Tested?
Checklist