On Sat, Sep 26, 2020 at 8:17 AM Wes Turner <wes.turner@gmail.com> 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.