Edit Rename Changes History Upload Download Back to Top

Store butchering sprees

A couple of days ago I got inspired by this great message in my image
PostgreSQLServerBroker>>safelyExecuteBlock: aBlock 
        "^self 
        It seems that 'safely' in this context means: show the database busy cursor 
and look out for 'brokerSignals' and other exceptions.  Note that the halt is 
there because in some cases exceptions have been silently squashed, leaving 
no trace - I'd prefer to know what's happening.  This position should be 
reviewed at each release of StORE."

        self uglyMethod.
        ...
I have so often felt 'offended' by all those senders of #outer: and those exception handlers for UnhandledException that I went butchering my Store library in a let's-see-when-it-breaks spree.

Well, it seems it doesn't break if one doesn't wear shutters while butchering. I'll have to go back to count but I think I removed about 3/4 of the exception handlers from the store DB layer. The majority of them handled only one exception anyway, the connection lost notification, and whenever that happend would return an appropriate 'empty' answer thus 'lying' to the system and having the RB show unaltered packages.

I'm inspired to do some connection loss simulations to see how to handle these without littering exception handler idiom all over the place, but first I want to validate the store functionality. My problem is that I don't see any Store tests package in my installation.


Edit Rename Changes History Upload Download Back to Top