On Fri, Sep 25, 2020 at 8:09 PM Chris Angelico
On Sat, Sep 26, 2020 at 8:17 AM Wes Turner
wrote: What a worthless semantic distinction.
You don't want to be executing code to determine why an Exception
occurred because you do not trust support devs to access all of the data in the production system.
"Exceptions happen" is true, but that's not satisfactory in an
organization focused on quality.
.... wut?
I don't understand what you mean here. Sometimes a traceback isn't all the information, and you need to add code to something to figure out the cause. Are you implying that, because I actually put effort into tracking bugs down, I am clearly not focused on quality??
I'll just go ahead and repeat myself: "what?"
- The context of this tangent was ~"[Exceptions happen in production] and that's okay". - Looseness with exception handling is entirely unacceptable for safety-critical and high availability applications. - *Interactive debugging* is fine for many non-production applications. - Yup, the process spawner is going to reap and restart when the process fails due to an unhandled Exception, but data loss due to unhandled exceptions (and non-transactional data persistence) is a real problem - "It's just going to raise whatever sometimes and you can just pdb it every time" - You can add information to exceptions and preserve the traceback with `raise _ from _` I have nothing further to add about this non-personal tangent.