Hmm.  The 'delay_traps' context manager idea doesn't quite work here.  A problem occurs if (for example) an Overflow occurs during the with block;  in that case, Overflow should be raised at the end of the with block.  That's fine, except that we no longer know what sign it should be raised with---the flags accumulated in the temporary context that's active within the with block don't remember this information.  So something more elaborate (though probably still along the same lines) would be necessary.

The decimal module has a major defect that's making this awkward, namely that there's currently no easy way to implement custom trap handling.  A custom trap handler could simply record each exception as it occurred.  IEEE 754-2008 recommends that such trap handling exists (in section 8), though the language used is "should" (i.e., is recommended to), rather than "shall" (is required to).

One simple change that might help would be to have all Decimal exceptions derive from a common `DecimalException` superclass, making it easier to catch just decimal exceptions in a try-except block.