On Fri, Mar 10, 2023 at 6:15 AM Ralph Corderoy <ralph(a)inputplus.co.uk> wrote: Exception handling is a great leap sideways. it's a supercharged goto with steroids on top. In some ways more constrained, in other ways more prone to abuse. Example: I diagnosed performance problems in a program that would call into 'waiting' threads that would read data from a pipe and then queue work. Easy, simple, straightforward design. Except they used exceptions to then process the packets rather than having a proper lockless producer / consumer queue. Exceptions are great for keeping the code linear and ignoring error conditions logically, but still having them handled "somewhere" above the current code and writing the code such that when it gets an abort, partial work is cleaned up and trashed. Global exception handlers are both good and bad. All errors become tracebacks to where it occurred. People often don't disambiguate between expected and unexpected exceptions, so programming errors get lumped in with remote devices committing protocol errors get lumped in with your config file had a typo and /dve/ttyU2 doesn't exist. It can be hard for the user to know what comes next when it's all jumbled together. In-line error handling, at least, can catch the expected things and give a more reasonable error near to where it happened so I know if my next step is vi prog.conf or email support(a)prog.com. So it's a hate hate relationship with both. What do I hate the least? That's a three drink minimum for the answer. Warner