On Tue, Jun 7, 2011 at 09:19, <[email protected]> wrote: > Although in this specific case, the method in question is deprecated and > only there for legacy support. I think its okay to do the null check in > that case if needed. > > There were only a few callers that failed due to passing in nulls for the URL. I think I'll go with rjrjr's guidance and will drop this change.
> > On 2011/06/07 16:00:48, rjrjr wrote: > >> In general we try to be null-intolerant, although I don't know how >> consistent we are about it. Basically, nulls should never be quietly >> > cleaned > >> up for you but rather should fail fast if practical. If null is a >> > legal > >> value, it should serve a specific purpose. >> > > On Tue, Jun 7, 2011 at 12:44 AM, Thomas Broyer >> > <mailto:[email protected]> wrote: > > > On Tue, Jun 7, 2011 at 1:32 AM, Christoph Kern >> > <mailto:[email protected]> wrote: > >> > > It turns out it was easier to fix the specific case this broke in >> > client > >> > > code (a test that ended up passing null for a URL). >> > > Which raises the question, should Image gracefully handle "null" >> > for > >> > URLs, >> > > or should the API docs clarify that non-null values are expected? >> > Is > >> > there >> > > a convention for handling nulls in the GWT API? >> > >> > SafeHtmlUtils at least doesn't handle 'null' (and will throw NPEs). >> > I'd rather have SafeUri follow the same pattern, whether it is to >> > throw NPEs or is changed as proposed here for >> > unsafeCastFromUntrustedString. >> > >> > > > > http://gwt-code-reviews.appspot.com/1443814/ > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
