-
Notifications
You must be signed in to change notification settings - Fork 15
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
More workflow fixes #631
More workflow fixes #631
Conversation
d190b83
to
7ba6eed
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.
Generally, looks great! I left two minor comments that shouldnt take long to address. Thanks, @robertbartel!
try: | ||
return await self._process_request(request=request) | ||
except DmodRuntimeError as e: | ||
raise DmodRuntimeError(f"DMOD error when getting dataset state: {str(e)}") |
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.
To help provide more context, let's use raise from.
raise DmodRuntimeError(f"DMOD error when getting dataset state: {str(e)}") | |
raise DmodRuntimeError(f"DMOD error when getting dataset state: {str(e)}") from e |
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.
Don't we get this for free without the explicit usage, since we're inside the handling except
block?
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.
Yes and no. The call stack will propagate like you are suggesting, however the from
keyword is giving context that the exception we are raising now is a result of, in this case, e
. So, the stack trace will be more appropriately formatted. For example:
def raises():
raise RuntimeError("some runtime exception")
def normal_catch_and_reraise():
try:
raises()
except Exception as e:
raise RuntimeError(f"normal catch and reraise: {e}")
normal_catch_and_reraise()
Traceback (most recent call last):
File "/home/user/e.py", line 6, in normal_catch_and_reraise
raises()
File "/home/user/e.py", line 2, in raises
raise RuntimeError("some runtime exception")
RuntimeError: some runtime exception
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/user/e.py", line 16, in <module>
normal_catch_and_reraise()
File "/home/user/e.py", line 8, in normal_catch_and_reraise
raise RuntimeError(f"normal catch and reraise: {e}")
RuntimeError: normal catch and reraise: some runtime exception
def catch_and_reraise_from():
try:
raises()
except Exception as e:
raise RuntimeError("catch and reraise from") from e
catch_and_reraise_from()
Traceback (most recent call last):
File "/home/user/e.py", line 12, in catch_and_reraise_from
raises()
File "/home/user/e.py", line 2, in raises
raise RuntimeError("some runtime exception")
RuntimeError: some runtime exception
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/user/e.py", line 16, in <module>
catch_and_reraise_from()
File "/home/user/e.py", line 14, in catch_and_reraise_from
raise RuntimeError("catch and reraise from") from e
RuntimeError: catch and reraise from
Notice the presence of The above exception was the direct cause of the following exception:
in the second stack trace.
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.
Ah, I see. Reviewing the documentation (too quickly) yesterday, I read the part about an implicit mechanism when already being handled, and missed where that actually involves a different exception object attribute. I've made a change, so please re-review when you have a moment.
python/services/partitionerservice/dmod/partitionerservice/service.py
Outdated
Show resolved
Hide resolved
Having ngen request default to geopackage format when building the domain for hydrofabric data requirements.
7ba6eed
to
0ebac5e
Compare
Additional fixes throughout the model exec workflow found in testing.