Or from op’s example, an insert_all that raises a constraint error, which means it won’t treat “exceptional” (pun intended) cases at all, so you have to be explicit about the failing cases - got it.
Hey @josevalim, yes of course! I think that the “tricky part” here (hence OP’s question), is that the transaction/2 spec shows that it returns an error tuple. So one could assume it should be safe at a first glance. But again, like was shown in the thread, the other part is also documented.
From how the naming convention is phrased, it gives the impression that it’s always one or the other (but again, we don’t have a paired function here as well):
Many functions come in pairs, such as
File.read/1andFile.read!/1.File.read/1will return a success or failure tuple, whereasFile.read!/1will return a plain value or else raise an exception:
So, this use case signals to me is that is perfectly possible to have a “”“unsafe”“” function that still returns an error tuple, is that right?
Yes, that was a poor example. I didn’t understand what @jeremyjh meant by “thunk” in the previous comment. I agree it is not the same use case. That helped clearing things out a bit.
