Spec discussion: Exception and Error Handling in Meltano #6700
Replies: 5 comments 10 replies
-
To start off the conversation, some steps we could start tackling:
|
Beta Was this translation helpful? Give feedback.
-
This topic came up in Hacker News recently and got quite heated, so it isn’t just us figuring out Exceptions vs Errors 😅 |
Beta Was this translation helpful? Give feedback.
-
We should ensure we are using raise-from whenever we are raising an exception from within an try:
something_that_might_raise_an_exception()
except SomeExceptionType:
raise OtherExceptionType('error message') Do this: try:
something_that_might_raise_an_exception()
except SomeExceptionType as ex:
raise OtherExceptionType('error message') from ex This sets the A good explanation of this can be found here: https://stackoverflow.com/a/24752607/5946921 |
Beta Was this translation helpful? Give feedback.
-
Something that should be avoided that I've seen throughout the Meltano codebase is this pattern: try:
something_that_might_raise_an_exception()
except SomeExceptionType as ex:
logger.error(f'Oh no! An error: {ex}') This implicitly calls The stdlib Structured logging helps with this, because with that you can log the exception object itself, and then that can be processed as the user wishes (often with some difficulty, but better than losing the exception object altogether). |
Beta Was this translation helpful? Give feedback.
-
Related: #6641 |
Beta Was this translation helpful? Give feedback.
-
Opening this new discussion to come to a global set of standards for how we want to handle exceptions and errors within Meltano.
For this discussion (until another proposal is raised):
Some issues we have as of now which we'd want to address:
raise SomeException()
sufficient or should we calllogging.exception
?cc @pandemicsyn, @WillDaSilva, @edgarrmondragon, @meltano/engineering
Beta Was this translation helpful? Give feedback.
All reactions