Chronos is one of the many Smalltalk-related blogs syndicated on Planet Smalltalk
χρόνος

Discussion of the Essence# programming language, and related issues and technologies.

Blog Timezone: America/Los_Angeles [Winter: -0800 hhmm | Summer: -0700 hhmm] 
Your local time:  

2006-04-25

Taking Exception To Smalltalk Exceptions

About 3 weeks ago, Cincom's James Robertson posted a blog entry that showcased Smalltalk's exception handling capabilities.

About three days later, some posters at Lambda The Ultimate took exception to the power of Smalltalk's exception handling capabilities [fixed URL]:

"So what you're saying is that you want to be able to bind exception throw behaviour dynamically, rather than lexically. The end result being that a caller can bind handler code into any (uncaught) exception throw, without having any way of knowing the source(s) of the possible exceptions, or their root cause.

How, exactly, is one supposed to document the exceptional behaviour of a library class in that case? What possible security gaurantees could one give, if a calling library can inject arbitrary code on any error condition, and ignore or mask the error as it will? How would you even exhaustively test such a thing, other than by ignoring the horrible stuff that your caller could have done to you and pretending you're in some some language?" -- Dave Griffith [I assume that "some some language" was intended to be "some sane language."]

I have news for Mr. Griffith: Programs Are Data. That truth is one of the pillars of computer science. Deal with it.

If programmers can't be trusted with the stack, they can't be trusted to assign the right value to a variable, nor to pass the right value as a parameter to a function. Compilers are tools, not hall monitors.


2 comments:

Anonymous said...

Your link "Lambda The Ultimate took exception to the power of Smalltalk's exception handling capabilities" does not point to Lambda the Ultimate.

Alan Lovejoy said...

You're right--so I've fixed it.