4 ms·

IMO, far better to log, then abort/core. I want to be able to inspect the state of the failed case, not just know that it failed.

catlifeonmars 7y ago
It’s far better to let the caller decide. As a user of a library, I absolutely do not want a library terminating my process. Sure, some programs can benefit from this, but some programs need to guarantee that they keep running. Being able to recover (Go’s counterpart to panic()) allows the caller to decide which behavior they want.
- hermitdev 7y ago
  I'm not sure I agree. There's a very, very small limited set of conditions that a client can recover from a condition that would trigger an assertion failure. Dont want an abort? Then use the release libs where those have been preprocesed out. Conversely, at a former employer we used a set of 3rd party database libs for ODBC on Linux that for the smallest config error would emit nothing to stderr and call exit(1) from a shared lib. that was beyond annoying
  - catlifeonmars 7y ago
    I was afraid someone would mention preprocessing out the asserts :) That also has its advantages, but would argue that it is impossible to selectively opt in or out. Honestly, for a well tested piece of code, the point is moot, since the assert(s) will never evaluate false anyway.
    - hermitdev 7y ago
      > I was afraid someone would mention preprocessing out the asserts :) Problem is, you need to understand what you're using, and like it or not, assert is defined as a macro by the C standard. And, assert is conditionally defined (and it's not the only conditionally defined macro). I know its long, verbose, and dry; but if you want to understand C (or C++ for that matter), you really need to read the ISO standards that correspond to the implantation.
      - drb91 7y ago
        You can also easily enable runtime failures so the point is indeed moot.
- int_19h 7y ago
  If you're in the same process as the code that had its invariant fail, how can you ensure that your process is in a safe state afterwards? A failed invariant, by definition, means that you're in uncharted territory - any anticipated failures are (assuming proper design) reported via the usual error mechanisms.

catlifeonmars 7y ago

It’s far better to let the caller decide. As a user of a library, I absolutely do not want a library terminating my process. Sure, some programs can benefit from this, but some programs need to guarantee that they keep running. Being able to recover (Go’s counterpart to panic()) allows the caller to decide which behavior they want.

hermitdev 7y ago
I'm not sure I agree. There's a very, very small limited set of conditions that a client can recover from a condition that would trigger an assertion failure. Dont want an abort? Then use the release libs where those have been preprocesed out. Conversely, at a former employer we used a set of 3rd party database libs for ODBC on Linux that for the smallest config error would emit nothing to stderr and call exit(1) from a shared lib. that was beyond annoying
- catlifeonmars 7y ago
  I was afraid someone would mention preprocessing out the asserts :) That also has its advantages, but would argue that it is impossible to selectively opt in or out. Honestly, for a well tested piece of code, the point is moot, since the assert(s) will never evaluate false anyway.
  - hermitdev 7y ago
    > I was afraid someone would mention preprocessing out the asserts :) Problem is, you need to understand what you're using, and like it or not, assert is defined as a macro by the C standard. And, assert is conditionally defined (and it's not the only conditionally defined macro). I know its long, verbose, and dry; but if you want to understand C (or C++ for that matter), you really need to read the ISO standards that correspond to the implantation.
    - drb91 7y ago
      You can also easily enable runtime failures so the point is indeed moot.
int_19h 7y ago
If you're in the same process as the code that had its invariant fail, how can you ensure that your process is in a safe state afterwards? A failed invariant, by definition, means that you're in uncharted territory - any anticipated failures are (assuming proper design) reported via the usual error mechanisms.