"I actually prefer nil. When I use 'errsafe, it's usually in a boolean context like (unless (errafe ...) ...)."
(unless (errsafe ... [nil]) ...)
Voila.
---
"I don't really follow, 'cause I don't know your code well enough to know which usage of 'errsafe you're talking about, but no worries."
Right now, you pass 2 functions to on-err, right? The first function receives the exception, if there is any. So what I'm saying is, we could change errsafe so it accepts a second argument, which would behave like the first argument to on-err:
(errsafe ... (fn (x) ...)) ; the variable x is the exception, if one is thrown
Which is somewhat nicer than doing the same thing with on-err:
(on-err (fn (x) ...)
(fn () ...))
---
"This way, if I say (errsafe:err "hey"), I get nil as usual, but if I say (errsafe (err "hey") it), then I get the exception."
Sounds neat.
---
"This way 'errsafe works a lot like 'or, trying several expressions one after another. I don't think I'd ever use this, though. ^_^"
Also sounds neat.
---
"For instance, oftentimes I'll return nil on failure and a singleton list on success, so that I can use the idioms (iflet (x) (foo a b c) ...) and (car:foo a b c). However, nil doesn't give much information about the failure, so occasionally I'll return (list t <result>) and (list nil <failure-message>) or (list 'success <result>) and (list 'failure <failure-message>)."
Sounds really ad-hoc. :P If I'm understanding correctly, that sounds like a manual version of failcall.
