Re: Does each DBI 'do' start a new transaction?

If you look at the DBI documentation, you'll see that the do method returns a success or failure status. In the code you've posted, you're throwing away that information. Developer Tip: Don't Do That.

Assume that any operation can fail, at any time. As soon as there's a failure, you have to report that error.

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

Comment on Re: Does each DBI 'do' start a new transaction? Download Code

Replies are listed 'Best First'.
Re^2: Does each DBI 'do' start a new transaction? by ikegami (Patriarch) on Mar 19, 2024 at 19:36 UTC
They're using an error handler (`$dbh->{HandleError}=\&handle_error;`)	[reply] [d/l]
Re^3: Does each DBI 'do' start a new transaction? by talexb (Chancellor) on Mar 20, 2024 at 13:26 UTC
I missed that. :( Now, what happens when there's a DBI error inside the error handler? Does it call itself until it hits the 'deep recursion' error? That would be a good place to locally delete the error handler and do something different with that error. Alex / talexb / Toronto Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.	[reply]
Re^2: Does each DBI 'do' start a new transaction? by etj (Priest) on Nov 07, 2024 at 16:04 UTC
I have learned through much pain that the most fun, comfortable way to program actually anything, is to deal with all errors when starting a new thing. Design how you're going to indicate errors (exceptions? return values? if so, as a struct, or as an enum?). Deal with incorrect inputs by returning errors. Then write tests checking all of those errors are being detected. And then start writing the substantive code. Then you have guaranteed-good inputs for the actual program/function, which is surprisingly nice. Any other approach is more painful and takes longer. An unexpected (for me) illustration of this approach's value was very recent, when I was using the newly-incorporated Test::PDL to update all the tests of PDL to use `is_pdl`, which checks types, dimension, bad value patterns, NaNs, numerical values, and reports in some detail any failures. The tests thus modified are SO much simpler, with no need for extra code to dump any incorrect inputs, and have actually caught at least one bug (incorrect handling of converting a negative floating-point number into an unsigned value - on ARM, it gets a 0, even though on Intel it gets the INT_MAX+number+1).	[reply] [d/l]