On 6-Nov-05, at 3:02 PM, Cees De Groot wrote:
>
> Anyway, how would you rewrite #error: to throw the exception the
> sender meant to throw, but didn't?
That's the crucial point; #error: is a nuke to crack a walnut. The  
only thing you can catch is the mother of all (well, almost all)  
exceptions and it gives you pretty much no useful information.

I think the problem in practical terms is that thinking of a suitable  
error and then putting proper handlers all over the place is a bugger  
of a job. Not to mention that for proper handling you need to have a  
sensible strategy for layering the exceptions  so that a 'missing  
directory' error from the FileDirectory level gets turned into a  
'resource not available' for the application and eventually a nice  
dialogue for the user that explains that the track they wanted could  
not be played because someone seems to have unmounted the disc it is  
supposed to be on. Sure, you could let FileDirectory>fileNamed: raise  
"self error: 'directory not there dumbo'" but you won't make any  
friends. A proper missing directory exception means some code  
handling it might be able to attempt automounting other discs or  
redirecting to a network or whatever. A missing resource exception at  
the next level allows the application to  do something suitable which  
hopefully includes fixing the problem so the user never needs to know  
there was a problem.

It's similar to sending a message so that the recipient gets to  
decide how to respond rather than stupid function calling rape and  
pillage. The big difference is that raising an exception goes up the  
execution stack to somewhere you cannot know at the point you raise it.

There's also a tools issue. I can't really pin it down but I've  
always (well, since 1989 when I first had to make prims and VM  
support for exceptions) felt that there is a need for some help in  
finding raisers and handlers of exceptions and in finding the right  
exception to use. There's sort of a yawning gap between a method  
where you see "BuggerItException raise" and where it might  get  
handled. I never felt that the defaultAction stuff did anything to  
help either.


tim
-- 
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim