On 6/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Rahul, every time I ask for something someone respond me ask me for a
use case,
<snip/>
Sorry if it seems that way, but in this particular thread I think "the
larger picture" should drive any code changes, and I thought it'd be
better understood once we put some usecases on the table.
In other words, we could:
o Define a new exception
* As you indicate below
* But I'm sure there are other error conditions (such as refering
to a non-existent state)
- Should that be another exception type?
- Should there be one generic "DialogException"?
o Channel these errors via onException() callbacks (as you originally
seemed to suggest)
* Should the dialog be determinated?
* Should the dialog remain in the current state (and wait for
further input)?
So, some thought needs to be given to the design so we have a lasting
congruous solution for all types of dialog error handling. Code
changes can then quickly follow.
but the point is:
Why don't throw a framework-specific exception like
"TransitionNotFoundException"?
Is so horrible? In my point of view, if a framework throw specific
exception would be a good idea... Craig told me the same think, so if
you agree I can open an RFC.
<snap/>
Sure sounds like an option (and presumably works sufficiently well for
all your usecases as well). You don't need me to agree before you open
any RFC, please feel free to open any tickets at will ;-)
-Rahul
However thanks for Shale and the time you spend for it!
Mario
