Well, I think it's generally a good thing to be able to distinguish mandatory stuff from optional stuff... and that's the use case of those two methods.
If you're getting a property which "must" be there in your domain you shouldn't have to check for null in all those cases, it feels so C-like to me... it should just return my value or else fail miserably so that I can see right then and there that there's a bug in my code (in this case the code which created my domain object or similar). And the one with the default value is great since I find myself passing in other things as well, not just null. I just couldn't live without any of them really. Just my point of view on this... 2010/1/5 Mattias Ask <[email protected]>: > Hi everyone, > > I have an issue which I would like your opinion on... It's mostly a question > of code aesthetics, to be honest, but still... > > When I look in my code I see myNode.getProperty(SOME_PROP, null); > everyehere... The reason for this is that I if I called > myNode.getProperty(SOME_PROP) I'd have to check for org.neo4j.api.core. > NotFoundException everywhere that I read properties that are not mandatory. > What if myNode.getProperty(SOME_PROP) was to return null instead? The doc > says explicitly that you can't persist null. If > myNode.getProperty(SOME_PROP) where to return null this would mean, without > any doubt, that the property does not exist, right? The upside to this would > be that I wouldn't have to use the DefaultReturnValue null everywhere. And > the argument that I'd have to null-check everywhere is kind of moot since I > already return null as DefaultReturnValue. > > In my case my domain objects extend a NodeDelegate, which takes an > underlaying node in the constructor. This means that I can use > getProperty(SOME_PROP, null) everytime I call getProperty(SOME_PROP)... but > the question is if there are any downsides to doing that? What are your > thoughts on this? > > Best, > Mattias Ask > _______________________________________________ > Neo mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [[email protected]] Neo Technology, www.neotechnology.com _______________________________________________ Neo mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
