Frank Schönheit - Sun Microsystems Germany <[EMAIL PROTECTED]> writes:
> > Sure, the need to enforce API > > constraints programmatically is still a valid point, e.g. a method > > returning a null reference though the API stated the returned ref is > > never null has to lead to a RuntimeException. > > But I rather would like this decoupled, e.g. > > > > Reference<foo::XBar> x(y->baz()[, UNO_QUERY]); > > assureNotNull(x); > > > > IMO more verbose, but clearer to read. > > [...] > > I don't like the additional line. That's basically how it's done today, > and this really becomes cumbersome over time. Writing the same pattern > again and again isn't really fun. > I think this is more about readability, and not about writability. And since code is read more often than written, I second Daniel's opinion. Which quite nicely brings us back to that ole error reporting/assertion cleanup/are-RuntimeExceptions-permitted-to-catch topic, as I pretty much assume assureNotNull is meant to assert something in a debug build. We should really, really start thinking about that now... Cheers, -- Thorsten If you're not failing some of the time, you're not trying hard enough. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
