FYI, here's the IRC discussion about this, for the record:
In clojure.java.jdbc there is a transaction function, which is supposed to rollback if the passed body throws an exception, but it only does that in case of an Exception, not any Throwable. What's the rationale behind this?
I'd want my transaction rolledback in case of any errors
seancorfield: maybe you can explain me this?
paraseba: catching Errors is generally a bad practice. i'm not saying it's wrong all the time, but Errors are often unrecoverable anyway
eg, "You ran out of heap space! I can't even allocate memory to throw an exception!"
but, even in the worst conditions, shouldn't we try to rollback the transaction? is not better that commiting in this unexpected error condition?
we can then rethrow the Throwable, after trying to rollback
paraseba: i don't think the db will commit if it gives you an error
and as amalloy, errors like OOM are best solved with exit()
lucian: it will ... jdbc is catching Exception and rolling back in that case .... but it commits in a finally
so, if you have an Error thrown, it will commit
I guess that's more surprising than a rollback
the logic is .... (try do-your-thing (catch Exception roll-back) (finally commit))
paraseba: well, then maybe you don't want to commit in finally?
I don't, not if I got an Error
lucian: i think he's upset that a library he's using is committing on error
amalloy: I can solve it easily by wrapping my operations in a catch Throwable -> rollback -> rethrow, but I think it's not the right behavior for the library
I would expect a commit only if the block ended without any kind of exceptions or errors. don't you agree ?
paraseba: meh. all kinds of weird stuff can happen if an Error occurs; i wouldn't be entirely certain that an attempt to "recover" makes things worse due to some weird program state caused by the Error. i mean, my completely-unresearched opinion is that catching Throwable would be better, but you can't really rely for your program's correctness on anything that happens after an Error
but, we are forcing a commit after an Error
the usual logic should be .... (do do-your-thing (commit)) if do-your-thing throws anything ... no commit is done. Puting a commit in a finally enforces the commit, even after Errors
yeah, i think i agree
amalloy: ok, I'll report an issue, thanks