Cool Things About Smalltalk
Alright, Avi Bryant is now blogging! Now, if that's not cool enough, he starts it off with a bang talking about exception handling in the Smalltalk world and how great it is. I have to agree with him! But, I thought I'd mention another cool thing about Smalltalk that I have been dearly missing in the Java world and that is to get ahold of the stack of any process. You see, all dialects of Smalltalk let you interregate the stack of any running process. In fact, this feature is what enabled Smalltalk to put in Continuations in most dialects so quickly. We know continuations are one good side effect of having access to the process stack, but what are others? How about these:
1) Serialize out the state of the stack at the time of an excpetion (this not mearly a stack dump, but the STATE of temporary variables, etc). I was on a project that Steve Wessells wrote a post-mortem utility that did just this. Let's just say it saved a LOT of time in debugging!!!!
2) Walking back up the stack to see who called you. Why might this be useful? Well, it means you can enforce a contract that only a certain object can call the method. You can also fire events based on methods on the stack. I did this recently for the record/playback functionality of the Agent Remote Control.
3) USE YOUR IMAGINATION!
I also wanted to add to the exception handling thread finally by saying that there's a lot to learn in Smalltalk's exception handling. Most Smalltalks also have what I call "last chance" handlers which are invoked when there are no primary handlers or they have all passed on the exception. Generally, most Smalltalks invoke the debugger when these second chance handlers are hit. I think this is very cool! I've tried to use them in Java, but they are generally linked to ThreadGroups and sometimes, you can't change a ThreadGroup's exception handler (or you wouldn't want to because you don't "own" it). But in these "last chance" handlers I've done some cool stuff including resuming the exception from them! Think about it this way: You could do something in your last chance handler like collect garbage or write a log entry and then resume the signal. You can go crazy!
But, alas, I generally don't go too nuts with either of these cool things in Smalltalk. Exceptions are cool, but I generally try not to use too many and use them only when needed. I also don't spend a lot of time feddling with the stack even though its fun. My general rule is when you need it, you know it....There's been several times where I wish Java had the same facilities that Smalltalk does (especially for reporting on the state of a production system that has just blown itself out of the water). I can't tell you how many times, I'm looking at a dead Java stack trace and wondering: this gives me not enough information to figure out why it died. Telling me what methods were called tells me little to nothing about the state of the application at time of death. It's those darn little objects and temporary variables that generally tell the story of an object gone bad...=)
Well, I'm off to bed to fight my terrible cold.....=)