to clarify, can you provide an example of what does not work well and detail / code of what would work well?
ie you say:
For me, it’s easy within a minute to hone down on actually what this bare exception is telling me, I don’t have to dig through other weird `try:except` logic that might have been triggered and buried the problem.
so you are saying or propsing to just have not try:except or what would the code you write look like in the absence of try:except
Nothing and just let the program/pipeline error out and read the raw stack trace. Much easier to follow than sifting through try/except stack trace. Plus keeps the code more readable without all those try/except blocks.
Might seem like bad practice, but 99% of the time I think you just want your pipeline to exit exactly where the error occurred and return the raw stack trace in the logs. Maybe one exception would be if you needed some cleanup steps or something similar after a failure, which would fit nicely in the except block.
To further clarify --- do you just feel the need to not use try/except or is it try statements in general ie let's say for the use case of try/finally -- ie the use case being:
there is a a database connection, and you wanted to make sure it was cleaned up, even if an error occurred in the try block
to clarify, can you provide an example of what does not work well and detail / code of what would work well?
ie you say:
For me, it’s easy within a minute to hone down on actually what this bare exception is telling me, I don’t have to dig through other weird `try:except` logic that might have been triggered and buried the problem.
so you are saying or propsing to just have not try:except or what would the code you write look like in the absence of try:except
in a try except block, you can raise the error and that entire error log dump will show
I see that you knocked try: execpt for error handling, but can you share what you then do as a superior alternative?
Nothing and just let the program/pipeline error out and read the raw stack trace. Much easier to follow than sifting through try/except stack trace. Plus keeps the code more readable without all those try/except blocks.
Might seem like bad practice, but 99% of the time I think you just want your pipeline to exit exactly where the error occurred and return the raw stack trace in the logs. Maybe one exception would be if you needed some cleanup steps or something similar after a failure, which would fit nicely in the except block.
To further clarify --- do you just feel the need to not use try/except or is it try statements in general ie let's say for the use case of try/finally -- ie the use case being:
there is a a database connection, and you wanted to make sure it was cleaned up, even if an error occurred in the try block
@Michael