> Status style guide
FWIW, we eschew exceptions not because of performance concerns ("inefficient
implementation", zero-cost, number-of-bytes-overhead etc) but cognition
concerns - it's difficult to read, reason about and audit code in the presence
of exceptions for a few (main) reasons:
* invisible at call site - there is no indication at call sites that a
particular function call has an alternate, invisible code path that will be
taken on errors - this leads to code not handling
_[recoverable](https://forum.nim-lang.org/postActivity.xml#recoverable) errors
at the right layer of abstraction - this is frequently seen in the std lib for
example in the form of resource leaks or unhandled corner cases, but it's also
been a source of numerous bugs and security issues in our own code base - not
using exceptions has significantly improved the quality of error and edge case
handling in our codebase.
* invisible in function signature - there is no indication in the function
signature that the function has an alternate return type - this impacts
maintainability, because the raised exceptions form a part of the API of a
function - raising a _[new](https://forum.nim-lang.org/postActivity.xml#new)
exception, is a breaking change in most cases, but this is not reflected at
compile time with a change to the (explicit) signature, which prevents the
compiler from detecting downstream breakage - likewise, removing the raising of
an exception creates dead code paths in calling code.
* dynamic typing - Exception and its friends are dynamically typed which
again makes reasoning about them at compile / audit time difficult - this fits
poorly with our otherwise statically type-checked codebase - in our
applications in particular, we don't want the error handling code paths to be
of lower quality in this regard.
Using exceptions for panics (go, rust) is a different and mostly unrelated /
orthogonal topic - here, they're not part of the "normal" code flow that
programmers use in their day-to-day prose, and if they were turned into `quit`
without unwinding, no significant/intended functionality is lost - exceptions
or not at this stage is an implementation detail.
The background here is that we're not using Nim as a scripting language, but
rather to produce a long-running, stand-alone application. In a script, errors
and leaks are cheap because you restart the script and that's it - in a
long-running application, the error code paths are _equally
[important](https://forum.nim-lang.org/postActivity.xml#important) to the
"normal" code paths, and we want an error handling mechanism that reflects this.
