On Fri, Sep 25, 2020 at 04:58:00PM -0400, Wes Turner wrote:
On Fri, Sep 25, 2020 at 1:43 PM Steven D'Aprano
wrote:
Of course rare or unusual exceptions probably won't be discovered without a lot of testing, including stress testing, or not until the code goes out into production. That's okay.
While there are plenty of ways to debug in production, debugging in production is a bad idea and is not allowed (because: __, __, __) : log the exception with necessary details (traceback, exception attrs, <full stack frame>) but exclude sensitive information that shouldn't be leaking into the logging system.
I hear you about sensitive information leaking into the logging system. But production code is not necessarily used by a third party where such leaks are a concern. In a perfect world, our code would be 100% bug-free when we release it into production. And we have some strategies aimed to help approach that: TDD, fuzzing, test coverage metrics, etc. If we are writing software that could kill people if we get it wrong: https://hackaday.com/2015/10/26/killed-by-a-machine-the-therac-25/ this level of care is justified. But under normal circumstances, don't let the perfect get in the way of the good. "Good enough" depends on what the code does and the consequences of a failure. https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good In practice, we have a number of competing desires. We want the software for a reason, and we might not want to wait for it to be absolutely 100% bug free before actually using it in production. (Especially since we can never be sure that it is bug-free.) So we have to expect some bugs will be reported from production. This is fine. We shouldn't let purists bully or shame us into thinking that this is necessarily the wrong thing. Sometimes "good enough, right now" is better than "perfect, in three years". -- Steve