Comment on big no by Michael Lucas-Smith
Well, the sort of thing that springs to mind is this:
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.