From: Benjamin F. <ben...@he...> - 2012-03-08 10:12:46
|
On Thursday, March 08, 2012, Andrew Johnson wrote: > On 2012-03-07 Benjamin Franksen wrote: > > Yes, returning an empty string is a bad idea. But throwing an exception > > or even asserting 'not top-level' is a bit too drastic IMO, the caller > > might not (yet) know whether this is a top-level object. So I'd say it > > should return null for 'does not exist' (if that is the case, i.e. > > top-level PVField). > > The problem with doing that is now all callers must check the return > value before they can use it, so instead of Marty's simple expression he > now has to declare a variable, assign getFieldName()'s return value to > it, test it for null and only then can he call .equals("value") on it. > [Maybe he should be assigning the name to a variable in that particular > case rather than writing pvField.getFieldName() multiple times, but > that's a side issue here; if it can return null he has to check before > he can call a method on it or risk a crash, which IMHO is worse than > triggering an assertion.] > > A top-level object is pretty different from most PVField objects, and no > code should be trying to pass one into methods that expect the PVField > to have a parent and/or a name. Throwing or asserting are the usual > means of telling the author of the calling routine that there's > something very wrong with their code, which I argue is the case here. > To go back to Marty's example, no code should be passing a top-level > object into his attach() method, and the sooner that gets flagged as a > bug the better. I am convinced. BTW, my argument was flawed. User code has no business querying the name of an arbitrary field (PVField). This makes sense only if user code /already knows/ that it is part of a structure. Is there a way to (systematically) annotate methods with pre- and post- conditions in Java? Does javadoc support that? Cheers Ben |