Re: Exception Handling for Quality
September 1, 2003, 7:26:17 pm

Spotted in Richard Demers Blog.

At the risk of beginning some sort of 'in breeding' smalltalking blog circle, I thought I'd throw me 2c in on this one. Exception's for UI's - big no!. Why? Well you're requiring the user of your domain library to wrap up ALL your exceptions. This, my friends, is manifest typing.

By Avi Bryant on September 2, 2003, 1:39:52 am

Sorry Michael, but I'm not sure what you mean here. Just cause you throw an exception doesn't mean it has to be handled - that's what #defaultAction is for (at least in Squeak, I don't know if the VW or VAST protocol is the same). And "manifest typing"? How so?

By Michael Lucas-Smith on September 2, 2003, 3:23:38 am

Comment on big no by Michael Lucas-Smith

Well, the sort of thing that springs to mind is this:

[[aDomainObject doSomeFunction]
  when: SituationA do: [[:sig | sig resumeWith: true]
  	when: SituationB do: [[:sig | sig resumeWith: 'testing']
		when: SituationC do: [[:sig | ^SituationD signal]

In this sort of scenario, there is no default answer to the questions - why? because they're UI questions. They're UI questions because they need to ask the user something. So you have a heap of information that many be needed by the domain model, but as a programmer trying to use the domain model, you need to supply it to the domain model. This particular domain model doesn't provide a nice way of letting the programmer provide the 'possible' question answers.

So you end up with an Interface/API for your domain model that specifies, "You may get the following exceptions, A, B and C." .. because of the 'may' you almost always have to have a catch for them.

If there were a defaultAction for them.. why bother throwing them at all? you can provide a 'hook in' mechanism by actually coding it, instead of using exceptions as a 'do all' approach.