Condition Systems in an Exceptional Language - Chris Houser

"Some errors, however, are sufficiently obscure to escape detection for a surprisingly long time." -Brooker and Wheeler, 1952
Clojure does not come with a Condition system as powerful as Common Lisp's. Instead, we have Exceptions, which start unwinding the stack the moment they're thrown, destroying information as they go. The values of locals disappear, and there is no ability to continue from the location of the error. Several libraries solve this problem, but they do not compose well with each other. We will discuss these libraries, how they work, and why they don't compose. We will consider alternatives that may compose better, and the tradeoffs and amongst all of these.
About the speaker: Chris, a.k.a. Chouser, co-authored "The Joy of Clojure" and enjoys using Clojure regularly with the LonoCloud team at ViaSat.

[@DinHamburg]

this again shows the great power of common lisp

[@Joshua-lk9sg]

The biggest problem with the library-less approach is that it's harder to build restarts that require unwinding. Libraries with proper restart support include unwinding as an option, and will also be thread-safe (and some put in extra effort to remove laziness footguns with dynamic scope as well).
The readme for farolero I think is a good example of how you can provide an interface like what's proposed here while using a condition library internally to make it easier to handle unwinding etc.

[@c0okiemon5ter]

have a look at the newer clojure library "special" that implements conditions

[@Elite7555]

5:08 The problem with returning special values like Nil that I constantly face is, how would we know if the first element of the list wasn't actually Nil itself? It's like returning '0' for a failed string to integer conversion. This is a programming error. Throwing an Exception is appropriate. Also, special values tell you nothing about the cause of the error. If you need to communicate that a function could go wrong, but can't throw an Exception, indeed use a special type that could hold a value *or* an error.

[@nxtktube]

do not allow nil's in a list or a sequence for that matter, use a keyword like :empty instead '(1, 2, :empty, 3)