There have been several attempts to build this out prior, and while of course I’m sympathetic with the desired to steal the best idea in CL, I think the value is very limited in situations where this library doesn’t have wide uptake. The errors that you signal yourself have nice restartable properties, and the errors signaled by code you didn’t write (which is most of them IME) are boring old non-restartable Java exceptions.
Ironically this is a fantastic example of why when lispers say “macros make it so that you don’t need features in the core language; you can add them yourself” they’re only half-right. There is a certain class of feature that is only useful when it’s either included in the core language itself, or so widespread that it might as well be, because in some cases it matters whether or not the libraries you choose are using the feature.
Conditions is one pretty clear example, but I would also put pattern matching in this category–without pattern matching it’s almost unbearably tedious to represent exceptions as values by returning a tuple like [:ok "some-value"] vs [:error "not enough juice"] the way you do in Erlang. Of course lisps allow you to add pattern matching as a library; it’s also been done over and over again, but if it’s not built-in to the language/ecosystem then the libraries you use will not use this pattern of representing errors. Because of this a third-party pattern matching library is much worse than a built-in pattern matcher, and this is one of the biggest mistakes that Clojure makes.
There have been several attempts to build this out prior, and while of course I’m sympathetic with the desired to steal the best idea in CL, I think the value is very limited in situations where this library doesn’t have wide uptake. The errors that you signal yourself have nice restartable properties, and the errors signaled by code you didn’t write (which is most of them IME) are boring old non-restartable Java exceptions.
Ironically this is a fantastic example of why when lispers say “macros make it so that you don’t need features in the core language; you can add them yourself” they’re only half-right. There is a certain class of feature that is only useful when it’s either included in the core language itself, or so widespread that it might as well be, because in some cases it matters whether or not the libraries you choose are using the feature.
Conditions is one pretty clear example, but I would also put pattern matching in this category–without pattern matching it’s almost unbearably tedious to represent exceptions as values by returning a tuple like
[:ok "some-value"]vs[:error "not enough juice"]the way you do in Erlang. Of course lisps allow you to add pattern matching as a library; it’s also been done over and over again, but if it’s not built-in to the language/ecosystem then the libraries you use will not use this pattern of representing errors. Because of this a third-party pattern matching library is much worse than a built-in pattern matcher, and this is one of the biggest mistakes that Clojure makes.