Any way to peek at the exception currently being thrown?

[Steven Schveighoffer]

On 6/17/21 5:51 PM, kdevel wrote:
> On Thursday, 17 June 2021 at 20:59:06 UTC, Steven Schveighoffer wrote:
> 
> [...]
> 
>>> Why don't you make the COMMIT explicit (by implementing commit 
>>> method) and let the destructor ROLLBACK the transactino unconditionally?
>>
>> Yeah, that's possible, but then I still have to do:
>>
>> auto txn = conn.beginTransaction;
>> scope(success) txn.commit;
>>
>> In which the `commit` call only does something on the outer-most txn.
>>
>> Not much better. And a bit awkward.
> 
> You have nested transactions txn1, ... txnN. Then there is a path thru 
> the code having a line when all transactions are to be commited. Why 
> don't you explicitly write
> 
>     tnxN.commit;
>     :
>     tnx1.commit;
> 
> or whatever the appropriate order is? Why do you hide the commit (side 
> effect!) in a scope exit?
> 
> 

Transactions don't nest (this is mysql). So calling "START TRANSACTION" 
actually commits any in-progress transaction.

This is why I need something like a counter, and I increment and 
decrement the counter instead of actually beginning and committing the 
transaction.

A transaction is an atomic change to the database. Let's say I have 2 
library types that have a `saveToDB` function. Each of those might have 
multiple SQL statements they use, which I want to be atomic. But I also 
might want to save both of them at once and have *that* be atomic.

Right now, I just put the transactions at the highest level, and the 
types cannot enforce atomicity of their own storage.

Really, there are 2 problems here. One is that I want to avoid having to 
type out those 3 lines. The other is that I want to implement some sort 
of re-entrant transactions, which can be done already without language help.

But something like a `scope(failure) ~this()` mechanism might be useful 
for the first problem.

-Steve