On 21 Aug., 15:50, Martin Wildam <mwil...@gmail.com> wrote: > I think the problem of context you also have when dealing with an > exception on the low level. Context is known most likely only by some > parent caller but on the other hand the parent caller often does not > have any clue about how some functionality has been implemented on the > low level and hence either does not really know what happens.
Oh with context, I was more thinking about supplying additional information from down below where the exception got thrown. Think of an input field of a some complex UI, say an IDE's property editor. If you supply invalid input, the component's model (or observers of it) can raise a PropertyVetoException and supply the original PropertyChangeEvent as a member. When you catch this PropertyVetoException higher up, you can use the PropertyChangeEvent member to see which property you're dealing with, what the value was originally and what the user tried to enter. So you show an error dialog with this information as well as pointing out constraints of the particular input in question. Conceptually, you pass new context backwards on the existing call stack. This can be abused of course, primarily concern being leaking abstractions. However it beats having to deal with a tangled decentralized web of conditionals and shared variables to get to the same context. /Casper --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
