This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Exception Handling in Development
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
I posted earlier on exception handling in BottomFeeder. Later on, Rich chimed in with the uses and abuses of exception handling. Certainly you can go overboard, and many people starting with Smalltalk do - it's veryeasy to just grab all exceptions and swallow them - and then have no frelling idea why things aren't working right.
In fact, that was a problem I had early on in BottomFeeder - the code that grabbed the feeds was swallowing exceptions so far down in the network code layer, that all errors came back to the UI as basically "no response". That was no good - it made it impossible to separate recoverable errors (like, say, a redirect that could be followed to the new location) from the non-recoverable ones (a 404, document not found).
What I ended up doing over time was moving the right handlers to the right place - things like a redirect are now silently - and properly - handled, while an inability to read a site that we can normally read is simply ignored. One of the lessons I learned early on in Bf was that there are scads of network errors for which the appropriate client response is to mostly treat it as no update at this time - on the assumption that it would likely work fine next time. For instance, say you left the application running overnight, and storms knocked out your network service (but not your power). Every http query will result in an error until the network comes back up - but these are all transient
Previous Topic
