I share Ray's suspicion that this won't actually be much of a problem. A checked exception is clearly (I hope) the wrong way to go. Checked exceptions have their place, but they are a major pain in several anatomical locations when declared in situations where the vast majority of the time they cannot occur. On the other hand, unchecked exceptions for inputs that are unacceptable are quite normal (ArrayIndexOutOfBoundsException comes to mind). Nulls even have their own exclusive exception for unacceptability. Throwing exceptions like those can be left up to the individual HasValue implementation and developers will be accustomed to seeing and handling them.
I think Ian's idea of a read-only interface is interesting, but not really on topic. Perhaps it deserves its own thread? On Mon, Dec 1, 2008 at 5:50 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > As many of you know, we have started down the path of making our form > widgets implement HasValue. A question that has come up is: Should widgets > be able to chose what values the widget accepts (i.e. setValue(null) for a > text box or a bounded integer range for a select box) without throwing > runtime exceptions? > > So, for instance, assuming we allow setValue(null) in some cases and not > others: > > HasValue<Date> dateBox = new DateBox(); > HasValue<String> hasValue2 = new TextBox(); > > // This clears the date box. > hasValue1.setValue(null); > > // This throws an illegal argument exception. > hasValue2.setValue(null); > > > The HasValue interface becomes a lot more difficult to implement if we > insist that all non-null values are supported, it becomes slightly harder to > use if we do not. > > So, which contract should we enforce? > > > Proposal 1) > setValue() gives no guarantee about whether a specific value is valid. > Users must know the underlying widget is in order to safely use the HasValue > interface. > > Proposal 2) > setValue() will accept all non-null values of a specific type as valid > input. In order to implement this, we will have to introduce HasClearValue > to support clearing a widget. > > ListBox, for instance, would not be able to implement HasValue<String>, as > not all strings would be valid inputs. > > > > > > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
