-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Coverty triage, phase V #277
Conversation
Per our conversation. I am going to go through these and see if we can employ a different strategy in some cases, to avoid proliferation of null checks in the code.
|
That's probably a better choice - I started down the exception path in some cases, but then backed it out. I figured I'd toss this up as a discussion starter :) @rfecher @jwomeara @spohnan (Including the others) - |
Are we talking strictly about null return values? Generally, I think null
|
Yeah, return values specifically. |
I think null is OK sometimes. http://programmers.stackexchange.com/questions/120355/is-it-better-to-return-null-or-empty-values-from-functions-methods-where-the-ret
|
We just have to move to java 8 so we have Option! So something like the getDatastore() method. Returns null now if it can't get a datstore. I think it probably makes more sense to throw a DatastoreNotFound, IOException, or something else, right? Do we always expect it to find a datastore (I would say yes for method). Something that returns a collection, returning the equivalent of Collection.Empty is probably better as well. But I guess in a case where we had something that was GetFeature(String fid), it might make sense to return null if no feature was found (unless we expected somehow a feature to always be found, then an exception is fine). I guess in retrospect probably just echoing eric's first point, and expanding a little (tend to exceptions instead of null if it's handling an error). @rwgdrummer
|
Vast majority were just potential null pointer dereferences. With this we are down to 0.