Missing configuration option retrieval should return null rather than throw exception
See original GitHub issueHi.
Currently there is no mechanism to check if property exists, only to fetch it (and, probasbly, raise an exception). Since underlying exception is not a checked one, it’s terribly easy to miss, and (from my point of view) any map-like structures should return null on missing values to keep code consistent. So basically i suggest to:
- Add mechanism to check property presence (i.e.
hasProperty(String key)
) - Add mechanism to return default value in case there is no property set (i.e.
getProperty(String key, Class<T> type, T defaultValue)
) - Don’t throw exception whenever target property is not found, just return null; add
getRequiredProperty(String key, Class<T> type)
method that will throw exception if property is not found
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:9 (1 by maintainers)
Top Results From Across the Web
Should a retrieval method return 'null' or throw an exception ...
The exception would mean that there was a problem. If the value can be missing or present and both are valid for the...
Read more >Returning null or a empty value/throw exception? [duplicate]
This question already has answers here: Various programming books suggest that methods should not return null values (Clean Code for example). ...
Read more >Clean Code Tip: throw exceptions instead of returning null ...
When you don't have any fallback operation to manage null values (eg: retry pattern), you should throw an exception instead of returning ......
Read more >How to Fix and Avoid NullPointerException in Java - Rollbar
Incorrect configuration for dependency injection frameworks like Spring; Using synchronized on a null object; Throwing null from a method that ...
Read more >TRY...CATCH (Transact-SQL) - SQL Server - Microsoft Learn
Errors trapped by a CATCH block are not returned to the calling application. If any part of the error information must be returned...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hi @etki,
That’s a valid concern. Here’s what my approach to this problem has been so far.
Assumption: Your code should always know what settings you defined.
If the property is missing that means something went seriously wrong and thus an exception is being thrown. I see the following scenarios (and how to handle them) when you could run into this problem. I’m curious what your use case is. Is it one of the following or something else?
That said I see that such feature is a nice to have and I’m already working on it and should be able to ship it soon. Here’s the initial design. Let me know what are your thoughts on this. The initial design is as follows:
and via interface binding
So, we just got bitten by this - an interface bound to an environment config provider happily returned null, but bind it to a consulprovider, and the absence caused an exception. This was made worse by the fact that this new, optional, parameter was being applied against old configuration as it made no sense to update it as nothing had changed.
My problem with the assumption “Your code should always know what settings you defined.” is that “If the property is missing that means something went seriously wrong and thus an exception is being thrown” does not follow.
The former is stated through the interface contract. Java is a nullable language. An interface defining
Implies that NULL is a perfectly semantically valid return type from that interface - and for most K/V stores, the only way of recording NULL is through their complete absence.
Now being able to wrap that in Optional.absent() sounds great - as would supporting @Notnull type annotations to enhance that contract, but throwing an exception on absence feels like a defect to me.