Is there a better way to do an empty check in Java? [duplicate] The 2019 Stack Overflow...
Didn't get enough time to take a Coding Test - what to do now?
Example of compact Riemannian manifold with only one geodesic.
Do warforged have souls?
Could an empire control the whole planet with today's comunication methods?
Mortgage adviser recommends a longer term than necessary combined with overpayments
Is there a way to generate uniformly distributed points on a sphere from a fixed amount of random real numbers per point?
Identify 80s or 90s comics with ripped creatures (not dwarves)
Working through the single responsibility principle (SRP) in Python when calls are expensive
Deal with toxic manager when you can't quit
How many cones with angle theta can I pack into the unit sphere?
Is every episode of "Where are my Pants?" identical?
Am I ethically obligated to go into work on an off day if the reason is sudden?
Windows 10: How to Lock (not sleep) laptop on lid close?
Can I visit the Trinity College (Cambridge) library and see some of their rare books
How to make Illustrator type tool selection automatically adapt with text length
Single author papers against my advisor's will?
"... to apply for a visa" or "... and applied for a visa"?
Circular reasoning in L'Hopital's rule
how can a perfect fourth interval be considered either consonant or dissonant?
Why can't devices on different VLANs, but on the same subnet, communicate?
Can withdrawing asylum be illegal?
Did the UK government pay "millions and millions of dollars" to try to snag Julian Assange?
Why doesn't a hydraulic lever violate conservation of energy?
Is 'stolen' appropriate word?
Is there a better way to do an empty check in Java? [duplicate]
The 2019 Stack Overflow Developer Survey Results Are In
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
The Ask Question Wizard is Live!
Data science time! April 2019 and salary with experienceHow to check multiple objects for nullity?Check chains of “get” calls for nullHow better refactor chain of methods that can return null in java?Check if last getter in method chain is not nullTry-Catch Instead of Null Check When Using Several Getterstry/catch vs null check in javaTry Catch Performance JavaIs Java “pass-by-reference” or “pass-by-value”?How do I efficiently iterate over each entry in a Java Map?What is the difference between public, protected, package-private and private in Java?Fastest way to determine if an integer's square root is an integerHow do I read / convert an InputStream into a String in Java?When to use LinkedList over ArrayList in Java?How do I generate random integers within a specific range in Java?What's the simplest way to print a Java array?How do I convert a String to an int in Java?Creating a memory leak with Java
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
20
This question already has an answer here:
Check chains of “get” calls for null
8 answers
Check if last getter in method chain is not null
3 answers
How to check multiple objects for nullity?
5 answers
Try-Catch Instead of Null Check When Using Several Getters
3 answers
How better refactor chain of methods that can return null in java?
10 answers
This might look like a primitive question or a this could be done by a simple utility library method that I don't know about.
The goal is to check the value of a boolean field that is nested under two objects.
private boolean sourceWebsite(Registration registration) {
Application application = registration.getApplication();
if (application == null) {
return true;
}
Metadata metadata = application.getMetadata();
if (metadata == null) {
return true;
}
Boolean source = metadata.getSource();
if (source == null) {
return true;
}
return !source;
}
I know this could be done in a single if(). I have added multiple ifs here for the sake of readability.
Is there a way that we could simplify the above if statements and have a simple utility class that returns the value of Boolean source if the parent objects or not null?
java if-statement conditional
edited yesterday
Peter Mortensen
13.9k1987114
asked yesterday
codeMancodeMan
4,44721646
marked as duplicate by Sotirios Delimanolis java
Users with the java badge can single-handedly close java questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
yesterday
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
20
This question already has an answer here:
Check chains of “get” calls for null
8 answers
Check if last getter in method chain is not null
3 answers
How to check multiple objects for nullity?
5 answers
Try-Catch Instead of Null Check When Using Several Getters
3 answers
How better refactor chain of methods that can return null in java?
10 answers
This might look like a primitive question or a this could be done by a simple utility library method that I don't know about.
The goal is to check the value of a boolean field that is nested under two objects.
private boolean sourceWebsite(Registration registration) {
Application application = registration.getApplication();
if (application == null) {
return true;
}
Metadata metadata = application.getMetadata();
if (metadata == null) {
return true;
}
Boolean source = metadata.getSource();
if (source == null) {
return true;
}
return !source;
}
I know this could be done in a single if(). I have added multiple ifs here for the sake of readability.
Is there a way that we could simplify the above if statements and have a simple utility class that returns the value of Boolean source if the parent objects or not null?
java if-statement conditional
edited yesterday
Peter Mortensen
13.9k1987114
asked yesterday
codeMancodeMan
4,44721646
marked as duplicate by Sotirios Delimanolis java
Users with the java badge can single-handedly close java questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
yesterday
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
20
20
20
2
This question already has an answer here:
Check chains of “get” calls for null
8 answers
Check if last getter in method chain is not null
3 answers
How to check multiple objects for nullity?
5 answers
Try-Catch Instead of Null Check When Using Several Getters
3 answers
How better refactor chain of methods that can return null in java?
10 answers
This might look like a primitive question or a this could be done by a simple utility library method that I don't know about.
The goal is to check the value of a boolean field that is nested under two objects.
private boolean sourceWebsite(Registration registration) {
Application application = registration.getApplication();
if (application == null) {
return true;
}
Metadata metadata = application.getMetadata();
if (metadata == null) {
return true;
}
Boolean source = metadata.getSource();
if (source == null) {
return true;
}
return !source;
}
I know this could be done in a single if(). I have added multiple ifs here for the sake of readability.
Is there a way that we could simplify the above if statements and have a simple utility class that returns the value of Boolean source if the parent objects or not null?
java if-statement conditional
edited yesterday
Peter Mortensen
13.9k1987114
asked yesterday
codeMancodeMan
4,44721646
This question already has an answer here:
Check chains of “get” calls for null
8 answers
Check if last getter in method chain is not null
3 answers
How to check multiple objects for nullity?
5 answers
Try-Catch Instead of Null Check When Using Several Getters
3 answers
How better refactor chain of methods that can return null in java?
10 answers
This might look like a primitive question or a this could be done by a simple utility library method that I don't know about.
The goal is to check the value of a boolean field that is nested under two objects.
private boolean sourceWebsite(Registration registration) {
Application application = registration.getApplication();
if (application == null) {
return true;
}
Metadata metadata = application.getMetadata();
if (metadata == null) {
return true;
}
Boolean source = metadata.getSource();
if (source == null) {
return true;
}
return !source;
}
I know this could be done in a single if(). I have added multiple ifs here for the sake of readability.
Is there a way that we could simplify the above if statements and have a simple utility class that returns the value of Boolean source if the parent objects or not null?
This question already has an answer here:
Check chains of “get” calls for null
8 answers
Check if last getter in method chain is not null
3 answers
How to check multiple objects for nullity?
5 answers
Try-Catch Instead of Null Check When Using Several Getters
3 answers
How better refactor chain of methods that can return null in java?
10 answers
java if-statement conditional
java if-statement conditional
edited yesterday
Peter Mortensen
13.9k1987114
asked yesterday
codeMancodeMan
4,44721646
edited yesterday
Peter Mortensen
13.9k1987114
asked yesterday
codeMancodeMan
4,44721646
edited yesterday
Peter Mortensen
13.9k1987114
edited yesterday
Peter Mortensen
13.9k1987114
edited yesterday
Peter Mortensen
13.9k1987114
13.9k1987114
asked yesterday
codeMancodeMan
4,44721646
asked yesterday
codeMancodeMan
4,44721646
asked yesterday
codeMancodeMan
4,44721646
4,44721646
marked as duplicate by Sotirios Delimanolis java
Users with the java badge can single-handedly close java questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
yesterday
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Sotirios Delimanolis java
Users with the java badge can single-handedly close java questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
yesterday
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
32
You can use java.util.Optional in this way:
private boolean sourceWebsite(Registration registration) {
return Optional.of(registration)
.map(Registration::getApplication)
.map(Application::getMetadata)
.map(Metadata::getSource)
.map(source -> !source)
.orElse(Boolean.TRUE);
}
In short, this will return true if any of the getters returns null, and !Metadata.source otherwise.
edited yesterday
Captain Man
3,29932855
answered yesterday
ernest_kernest_k
24.9k43151
9
Boolean.FALSE::equalsinstead ofsource -> !sourceif you really love method reference
– Adrian
yesterday
2
I think you meant ` Optional.ofNullable()`
– dehasi
yesterday
1
Sorry, you are right. I've upvoted :)
– dehasi
yesterday
1
Return type isbooleanso.orElse(true);would be better.
– user11153
yesterday
2
@user11153 The parameter requires a Boolean.. you give it a boolean and so it has to be boxed. It's not one unboxing less but one boxing more
– ave4496
yesterday
|
show 4 more comments
12
The following will return true if any one of is null. If all values are not null, it returns !source.
private boolean sourceWebsite(Registration registration) {
return registration.getApplication() == null
|| registration.getApplication().getMetadata() == null
|| registration.getApplication().getMetadata().getSource() == null
|| !registration.getApplication().getMetadata().getSource();
}
Updated :
If you want that every getter not called more than once then you can declare variable for every object like
private boolean sourceWebsite(Registration registration) {
Application application;
Metadata metadata;
Source source;
return (application = registration.getApplication()) == null
|| (metadata = application.getMetadata()) == null
|| (source = metadata.getSource()) == null
|| !source;
}
answered yesterday
Khalid ShahKhalid Shah
2,24021025
5
The null-conditional operator (?.) of c# is for shure a nice thing...
– keuleJ
yesterday
3
One problem I see is with that pattern is that it executes getApplication 4 times, getMetadata 3 times and getSource 2 times. If they are all trivial getters, this might not be that much of a problem. But if their implementation is non-trivial (or even worse: not side-effect free) this might become a problem.
– Philipp
yesterday
@Philipp yes. But in general getters are trivial.
– Khalid Shah
yesterday
5
In general they should be side-effect free, but that assumes that you are working with classes written by people who knew what they were doing and followed good software engineering principles and Java best practices. In the real world, that's a very brave assumption.
– Philipp
yesterday
1
@EricDuminil You generally can not rely on that. The JVM might be able to optimize these method calls away when they are trivial getters, but it might not be able to do that when they have some logic and it certainly won't be able to do it when they have side-effects.
– Philipp
yesterday
|
show 8 more comments
3
Another option you can use is a try-catch block. If you get a null pointer exception return true.
private boolean sourceWebsite(Registration registration) {
try {
return !registration.getApplication().getMetadata().getSource();
}
catch (NullPointerException e) {
return true;
}
}
answered yesterday
CaptianObviousCaptianObvious
5713
New contributor
CaptianObvious is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
6
You shouldn't use exceptions for program logic. Exceptions should be used in case of an unrecoverable state in a program where it's better to stop the entire flow rather than try and recover.
– Nzall
yesterday
1
In general I do agree with you (doing so might make the code harder to follow if it wasn't this short), and I feel that using Optional is correct choice here (assuming you are using a new enough version of java to have access to it). The question asked for a way to handle these checks without several null checks. This will do that.
– CaptianObvious
yesterday
1
@Nzall Exceptions can also be useful in program logic, for instance as a very readable way of checking if a string parses into a number which is very similar to CaptainObvious answer.
– Old Nick
yesterday
Backing up the comment from Nzall: stackoverflow.com/a/8255933/6296561 - TL;DR: exceptions are heavy
– Zoe
yesterday
Until a NPE is thrown much deeper in one of those methods.
– Koekje
yesterday
|
show 2 more comments
-1
You could do it using a hacky method like this:
public static Object get(Object o, String... m) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException {
if (o == null || m.length == 0) {
return null;
}
for (String m1 : m) {
o = o.getClass().getMethod(m1).invoke(o);
if (o == null) {
return null;
}
}
return o;
}
And call it like this:
Boolean source = (Boolean) get(registration, "getApplication", "getMetadata", "getSource");
return source == null ? false : !source;
But I wouldn't do it this way in any serious projects.
answered yesterday
Mika LammiMika Lammi
975619
2
This is bad code in so many aspects: slow, not controlled by the compiler, immune to refactoring aids from the IDE. Even you recognize that you wouldn't use this in any serious projects. But then: what's the point? No one would bother to post a question or even read the answers for unserious projects.
– julodnik
yesterday
It could become a bit better if you passed Methods as parameters instead of strings. It would probably look a bit likereturn Optional.of(registration).map(Registration::getApplication).map(Application::getMetadata).map(Metadata::getSource)so you might as well useOptionaldirectly. Still, I don't think you deserved downvotes. This method is still interesting as a thought experiment.
– Eric Duminil
yesterday
add a comment |
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
32
You can use java.util.Optional in this way:
private boolean sourceWebsite(Registration registration) {
return Optional.of(registration)
.map(Registration::getApplication)
.map(Application::getMetadata)
.map(Metadata::getSource)
.map(source -> !source)
.orElse(Boolean.TRUE);
}
In short, this will return true if any of the getters returns null, and !Metadata.source otherwise.
edited yesterday
Captain Man
3,29932855
answered yesterday
ernest_kernest_k
24.9k43151
9
Boolean.FALSE::equalsinstead ofsource -> !sourceif you really love method reference
– Adrian
yesterday
2
I think you meant ` Optional.ofNullable()`
– dehasi
yesterday
1
Sorry, you are right. I've upvoted :)
– dehasi
yesterday
1
Return type isbooleanso.orElse(true);would be better.
– user11153
yesterday
2
@user11153 The parameter requires a Boolean.. you give it a boolean and so it has to be boxed. It's not one unboxing less but one boxing more
– ave4496
yesterday
|
show 4 more comments
32
You can use java.util.Optional in this way:
private boolean sourceWebsite(Registration registration) {
return Optional.of(registration)
.map(Registration::getApplication)
.map(Application::getMetadata)
.map(Metadata::getSource)
.map(source -> !source)
.orElse(Boolean.TRUE);
}
In short, this will return true if any of the getters returns null, and !Metadata.source otherwise.
edited yesterday
Captain Man
3,29932855
answered yesterday
ernest_kernest_k
24.9k43151
9
Boolean.FALSE::equalsinstead ofsource -> !sourceif you really love method reference
– Adrian
yesterday
2
I think you meant ` Optional.ofNullable()`
– dehasi
yesterday
1
Sorry, you are right. I've upvoted :)
– dehasi
yesterday
1
Return type isbooleanso.orElse(true);would be better.
– user11153
yesterday
2
@user11153 The parameter requires a Boolean.. you give it a boolean and so it has to be boxed. It's not one unboxing less but one boxing more
– ave4496
yesterday
|
show 4 more comments
32
32
32
You can use java.util.Optional in this way:
private boolean sourceWebsite(Registration registration) {
return Optional.of(registration)
.map(Registration::getApplication)
.map(Application::getMetadata)
.map(Metadata::getSource)
.map(source -> !source)
.orElse(Boolean.TRUE);
}
In short, this will return true if any of the getters returns null, and !Metadata.source otherwise.
edited yesterday
Captain Man
3,29932855
answered yesterday
ernest_kernest_k
24.9k43151
You can use java.util.Optional in this way:
private boolean sourceWebsite(Registration registration) {
return Optional.of(registration)
.map(Registration::getApplication)
.map(Application::getMetadata)
.map(Metadata::getSource)
.map(source -> !source)
.orElse(Boolean.TRUE);
}
In short, this will return true if any of the getters returns null, and !Metadata.source otherwise.
edited yesterday
Captain Man
3,29932855
answered yesterday
ernest_kernest_k
24.9k43151
edited yesterday
Captain Man
3,29932855
edited yesterday
Captain Man
3,29932855
edited yesterday
Captain Man
3,29932855
3,29932855
answered yesterday
ernest_kernest_k
24.9k43151
answered yesterday
ernest_kernest_k
24.9k43151
answered yesterday
ernest_kernest_k
24.9k43151
24.9k43151
9
Boolean.FALSE::equalsinstead ofsource -> !sourceif you really love method reference
– Adrian
yesterday
2
I think you meant ` Optional.ofNullable()`
– dehasi
yesterday
1
Sorry, you are right. I've upvoted :)
– dehasi
yesterday
1
Return type isbooleanso.orElse(true);would be better.
– user11153
yesterday
2
@user11153 The parameter requires a Boolean.. you give it a boolean and so it has to be boxed. It's not one unboxing less but one boxing more
– ave4496
yesterday
|
show 4 more comments
9
Boolean.FALSE::equalsinstead ofsource -> !sourceif you really love method reference
– Adrian
yesterday
2
I think you meant ` Optional.ofNullable()`
– dehasi
yesterday
1
Sorry, you are right. I've upvoted :)
– dehasi
yesterday
1
Return type isbooleanso.orElse(true);would be better.
– user11153
yesterday
2
@user11153 The parameter requires a Boolean.. you give it a boolean and so it has to be boxed. It's not one unboxing less but one boxing more
– ave4496
yesterday
9
9
Boolean.FALSE::equals instead of source -> !source if you really love method reference– Adrian
yesterday
Boolean.FALSE::equals instead of source -> !source if you really love method reference– Adrian
yesterday
2
2
I think you meant ` Optional.ofNullable()`
– dehasi
yesterday
I think you meant ` Optional.ofNullable()`
– dehasi
yesterday
1
1
Sorry, you are right. I've upvoted :)
– dehasi
yesterday
Sorry, you are right. I've upvoted :)
– dehasi
yesterday
1
1
Return type is
boolean so .orElse(true); would be better.– user11153
yesterday
Return type is
boolean so .orElse(true); would be better.– user11153
yesterday
2
2
@user11153 The parameter requires a Boolean.. you give it a boolean and so it has to be boxed. It's not one unboxing less but one boxing more
– ave4496
yesterday
@user11153 The parameter requires a Boolean.. you give it a boolean and so it has to be boxed. It's not one unboxing less but one boxing more
– ave4496
yesterday
|
show 4 more comments
12
The following will return true if any one of is null. If all values are not null, it returns !source.
private boolean sourceWebsite(Registration registration) {
return registration.getApplication() == null
|| registration.getApplication().getMetadata() == null
|| registration.getApplication().getMetadata().getSource() == null
|| !registration.getApplication().getMetadata().getSource();
}
Updated :
If you want that every getter not called more than once then you can declare variable for every object like
private boolean sourceWebsite(Registration registration) {
Application application;
Metadata metadata;
Source source;
return (application = registration.getApplication()) == null
|| (metadata = application.getMetadata()) == null
|| (source = metadata.getSource()) == null
|| !source;
}
answered yesterday
Khalid ShahKhalid Shah
2,24021025
5
The null-conditional operator (?.) of c# is for shure a nice thing...
– keuleJ
yesterday
3
One problem I see is with that pattern is that it executes getApplication 4 times, getMetadata 3 times and getSource 2 times. If they are all trivial getters, this might not be that much of a problem. But if their implementation is non-trivial (or even worse: not side-effect free) this might become a problem.
– Philipp
yesterday
@Philipp yes. But in general getters are trivial.
– Khalid Shah
yesterday
5
In general they should be side-effect free, but that assumes that you are working with classes written by people who knew what they were doing and followed good software engineering principles and Java best practices. In the real world, that's a very brave assumption.
– Philipp
yesterday
1
@EricDuminil You generally can not rely on that. The JVM might be able to optimize these method calls away when they are trivial getters, but it might not be able to do that when they have some logic and it certainly won't be able to do it when they have side-effects.
– Philipp
yesterday
|
show 8 more comments
12
The following will return true if any one of is null. If all values are not null, it returns !source.
private boolean sourceWebsite(Registration registration) {
return registration.getApplication() == null
|| registration.getApplication().getMetadata() == null
|| registration.getApplication().getMetadata().getSource() == null
|| !registration.getApplication().getMetadata().getSource();
}
Updated :
If you want that every getter not called more than once then you can declare variable for every object like
private boolean sourceWebsite(Registration registration) {
Application application;
Metadata metadata;
Source source;
return (application = registration.getApplication()) == null
|| (metadata = application.getMetadata()) == null
|| (source = metadata.getSource()) == null
|| !source;
}
answered yesterday
Khalid ShahKhalid Shah
2,24021025
5
The null-conditional operator (?.) of c# is for shure a nice thing...
– keuleJ
yesterday
3
One problem I see is with that pattern is that it executes getApplication 4 times, getMetadata 3 times and getSource 2 times. If they are all trivial getters, this might not be that much of a problem. But if their implementation is non-trivial (or even worse: not side-effect free) this might become a problem.
– Philipp
yesterday
@Philipp yes. But in general getters are trivial.
– Khalid Shah
yesterday
5
In general they should be side-effect free, but that assumes that you are working with classes written by people who knew what they were doing and followed good software engineering principles and Java best practices. In the real world, that's a very brave assumption.
– Philipp
yesterday
1
@EricDuminil You generally can not rely on that. The JVM might be able to optimize these method calls away when they are trivial getters, but it might not be able to do that when they have some logic and it certainly won't be able to do it when they have side-effects.
– Philipp
yesterday
|
show 8 more comments
12
12
12
The following will return true if any one of is null. If all values are not null, it returns !source.
private boolean sourceWebsite(Registration registration) {
return registration.getApplication() == null
|| registration.getApplication().getMetadata() == null
|| registration.getApplication().getMetadata().getSource() == null
|| !registration.getApplication().getMetadata().getSource();
}
Updated :
If you want that every getter not called more than once then you can declare variable for every object like
private boolean sourceWebsite(Registration registration) {
Application application;
Metadata metadata;
Source source;
return (application = registration.getApplication()) == null
|| (metadata = application.getMetadata()) == null
|| (source = metadata.getSource()) == null
|| !source;
}
answered yesterday
Khalid ShahKhalid Shah
2,24021025
The following will return true if any one of is null. If all values are not null, it returns !source.
private boolean sourceWebsite(Registration registration) {
return registration.getApplication() == null
|| registration.getApplication().getMetadata() == null
|| registration.getApplication().getMetadata().getSource() == null
|| !registration.getApplication().getMetadata().getSource();
}
Updated :
If you want that every getter not called more than once then you can declare variable for every object like
private boolean sourceWebsite(Registration registration) {
Application application;
Metadata metadata;
Source source;
return (application = registration.getApplication()) == null
|| (metadata = application.getMetadata()) == null
|| (source = metadata.getSource()) == null
|| !source;
}
answered yesterday
Khalid ShahKhalid Shah
2,24021025
edited yesterday
answered yesterday
Khalid ShahKhalid Shah
2,24021025
answered yesterday
Khalid ShahKhalid Shah
2,24021025
answered yesterday
Khalid ShahKhalid Shah
2,24021025
2,24021025
5
The null-conditional operator (?.) of c# is for shure a nice thing...
– keuleJ
yesterday
3
One problem I see is with that pattern is that it executes getApplication 4 times, getMetadata 3 times and getSource 2 times. If they are all trivial getters, this might not be that much of a problem. But if their implementation is non-trivial (or even worse: not side-effect free) this might become a problem.
– Philipp
yesterday
@Philipp yes. But in general getters are trivial.
– Khalid Shah
yesterday
5
In general they should be side-effect free, but that assumes that you are working with classes written by people who knew what they were doing and followed good software engineering principles and Java best practices. In the real world, that's a very brave assumption.
– Philipp
yesterday
1
@EricDuminil You generally can not rely on that. The JVM might be able to optimize these method calls away when they are trivial getters, but it might not be able to do that when they have some logic and it certainly won't be able to do it when they have side-effects.
– Philipp
yesterday
|
show 8 more comments
5
The null-conditional operator (?.) of c# is for shure a nice thing...
– keuleJ
yesterday
3
One problem I see is with that pattern is that it executes getApplication 4 times, getMetadata 3 times and getSource 2 times. If they are all trivial getters, this might not be that much of a problem. But if their implementation is non-trivial (or even worse: not side-effect free) this might become a problem.
– Philipp
yesterday
@Philipp yes. But in general getters are trivial.
– Khalid Shah
yesterday
5
In general they should be side-effect free, but that assumes that you are working with classes written by people who knew what they were doing and followed good software engineering principles and Java best practices. In the real world, that's a very brave assumption.
– Philipp
yesterday
1
@EricDuminil You generally can not rely on that. The JVM might be able to optimize these method calls away when they are trivial getters, but it might not be able to do that when they have some logic and it certainly won't be able to do it when they have side-effects.
– Philipp
yesterday
5
5
The null-conditional operator (?.) of c# is for shure a nice thing...
– keuleJ
yesterday
The null-conditional operator (?.) of c# is for shure a nice thing...
– keuleJ
yesterday
3
3
One problem I see is with that pattern is that it executes getApplication 4 times, getMetadata 3 times and getSource 2 times. If they are all trivial getters, this might not be that much of a problem. But if their implementation is non-trivial (or even worse: not side-effect free) this might become a problem.
– Philipp
yesterday
One problem I see is with that pattern is that it executes getApplication 4 times, getMetadata 3 times and getSource 2 times. If they are all trivial getters, this might not be that much of a problem. But if their implementation is non-trivial (or even worse: not side-effect free) this might become a problem.
– Philipp
yesterday
@Philipp yes. But in general getters are trivial.
– Khalid Shah
yesterday
@Philipp yes. But in general getters are trivial.
– Khalid Shah
yesterday
5
5
In general they should be side-effect free, but that assumes that you are working with classes written by people who knew what they were doing and followed good software engineering principles and Java best practices. In the real world, that's a very brave assumption.
– Philipp
yesterday
In general they should be side-effect free, but that assumes that you are working with classes written by people who knew what they were doing and followed good software engineering principles and Java best practices. In the real world, that's a very brave assumption.
– Philipp
yesterday
1
1
@EricDuminil You generally can not rely on that. The JVM might be able to optimize these method calls away when they are trivial getters, but it might not be able to do that when they have some logic and it certainly won't be able to do it when they have side-effects.
– Philipp
yesterday
@EricDuminil You generally can not rely on that. The JVM might be able to optimize these method calls away when they are trivial getters, but it might not be able to do that when they have some logic and it certainly won't be able to do it when they have side-effects.
– Philipp
yesterday
|
show 8 more comments
3
Another option you can use is a try-catch block. If you get a null pointer exception return true.
private boolean sourceWebsite(Registration registration) {
try {
return !registration.getApplication().getMetadata().getSource();
}
catch (NullPointerException e) {
return true;
}
}
answered yesterday
CaptianObviousCaptianObvious
5713
New contributor
CaptianObvious is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
6
You shouldn't use exceptions for program logic. Exceptions should be used in case of an unrecoverable state in a program where it's better to stop the entire flow rather than try and recover.
– Nzall
yesterday
1
In general I do agree with you (doing so might make the code harder to follow if it wasn't this short), and I feel that using Optional is correct choice here (assuming you are using a new enough version of java to have access to it). The question asked for a way to handle these checks without several null checks. This will do that.
– CaptianObvious
yesterday
1
@Nzall Exceptions can also be useful in program logic, for instance as a very readable way of checking if a string parses into a number which is very similar to CaptainObvious answer.
– Old Nick
yesterday
Backing up the comment from Nzall: stackoverflow.com/a/8255933/6296561 - TL;DR: exceptions are heavy
– Zoe
yesterday
Until a NPE is thrown much deeper in one of those methods.
– Koekje
yesterday
|
show 2 more comments
3
Another option you can use is a try-catch block. If you get a null pointer exception return true.
private boolean sourceWebsite(Registration registration) {
try {
return !registration.getApplication().getMetadata().getSource();
}
catch (NullPointerException e) {
return true;
}
}
answered yesterday
CaptianObviousCaptianObvious
5713
New contributor
CaptianObvious is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
6
You shouldn't use exceptions for program logic. Exceptions should be used in case of an unrecoverable state in a program where it's better to stop the entire flow rather than try and recover.
– Nzall
yesterday
1
In general I do agree with you (doing so might make the code harder to follow if it wasn't this short), and I feel that using Optional is correct choice here (assuming you are using a new enough version of java to have access to it). The question asked for a way to handle these checks without several null checks. This will do that.
– CaptianObvious
yesterday
1
@Nzall Exceptions can also be useful in program logic, for instance as a very readable way of checking if a string parses into a number which is very similar to CaptainObvious answer.
– Old Nick
yesterday
Backing up the comment from Nzall: stackoverflow.com/a/8255933/6296561 - TL;DR: exceptions are heavy
– Zoe
yesterday
Until a NPE is thrown much deeper in one of those methods.
– Koekje
yesterday
|
show 2 more comments
3
3
3
Another option you can use is a try-catch block. If you get a null pointer exception return true.
private boolean sourceWebsite(Registration registration) {
try {
return !registration.getApplication().getMetadata().getSource();
}
catch (NullPointerException e) {
return true;
}
}
answered yesterday
CaptianObviousCaptianObvious
5713
New contributor
CaptianObvious is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Another option you can use is a try-catch block. If you get a null pointer exception return true.
private boolean sourceWebsite(Registration registration) {
try {
return !registration.getApplication().getMetadata().getSource();
}
catch (NullPointerException e) {
return true;
}
}
answered yesterday
CaptianObviousCaptianObvious
5713
New contributor
CaptianObvious is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
answered yesterday
CaptianObviousCaptianObvious
5713
New contributor
CaptianObvious is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered yesterday
CaptianObviousCaptianObvious
5713
answered yesterday
CaptianObviousCaptianObvious
5713
5713
New contributor
CaptianObvious is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
CaptianObvious is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
CaptianObvious is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
6
You shouldn't use exceptions for program logic. Exceptions should be used in case of an unrecoverable state in a program where it's better to stop the entire flow rather than try and recover.
– Nzall
yesterday
1
In general I do agree with you (doing so might make the code harder to follow if it wasn't this short), and I feel that using Optional is correct choice here (assuming you are using a new enough version of java to have access to it). The question asked for a way to handle these checks without several null checks. This will do that.
– CaptianObvious
yesterday
1
@Nzall Exceptions can also be useful in program logic, for instance as a very readable way of checking if a string parses into a number which is very similar to CaptainObvious answer.
– Old Nick
yesterday
Backing up the comment from Nzall: stackoverflow.com/a/8255933/6296561 - TL;DR: exceptions are heavy
– Zoe
yesterday
Until a NPE is thrown much deeper in one of those methods.
– Koekje
yesterday
|
show 2 more comments
6
You shouldn't use exceptions for program logic. Exceptions should be used in case of an unrecoverable state in a program where it's better to stop the entire flow rather than try and recover.
– Nzall
yesterday
1
In general I do agree with you (doing so might make the code harder to follow if it wasn't this short), and I feel that using Optional is correct choice here (assuming you are using a new enough version of java to have access to it). The question asked for a way to handle these checks without several null checks. This will do that.
– CaptianObvious
yesterday
1
@Nzall Exceptions can also be useful in program logic, for instance as a very readable way of checking if a string parses into a number which is very similar to CaptainObvious answer.
– Old Nick
yesterday
Backing up the comment from Nzall: stackoverflow.com/a/8255933/6296561 - TL;DR: exceptions are heavy
– Zoe
yesterday
Until a NPE is thrown much deeper in one of those methods.
– Koekje
yesterday
6
6
You shouldn't use exceptions for program logic. Exceptions should be used in case of an unrecoverable state in a program where it's better to stop the entire flow rather than try and recover.
– Nzall
yesterday
You shouldn't use exceptions for program logic. Exceptions should be used in case of an unrecoverable state in a program where it's better to stop the entire flow rather than try and recover.
– Nzall
yesterday
1
1
In general I do agree with you (doing so might make the code harder to follow if it wasn't this short), and I feel that using Optional is correct choice here (assuming you are using a new enough version of java to have access to it). The question asked for a way to handle these checks without several null checks. This will do that.
– CaptianObvious
yesterday
In general I do agree with you (doing so might make the code harder to follow if it wasn't this short), and I feel that using Optional is correct choice here (assuming you are using a new enough version of java to have access to it). The question asked for a way to handle these checks without several null checks. This will do that.
– CaptianObvious
yesterday
1
1
@Nzall Exceptions can also be useful in program logic, for instance as a very readable way of checking if a string parses into a number which is very similar to CaptainObvious answer.
– Old Nick
yesterday
@Nzall Exceptions can also be useful in program logic, for instance as a very readable way of checking if a string parses into a number which is very similar to CaptainObvious answer.
– Old Nick
yesterday
Backing up the comment from Nzall: stackoverflow.com/a/8255933/6296561 - TL;DR: exceptions are heavy
– Zoe
yesterday
Backing up the comment from Nzall: stackoverflow.com/a/8255933/6296561 - TL;DR: exceptions are heavy
– Zoe
yesterday
Until a NPE is thrown much deeper in one of those methods.
– Koekje
yesterday
Until a NPE is thrown much deeper in one of those methods.
– Koekje
yesterday
|
show 2 more comments
-1
You could do it using a hacky method like this:
public static Object get(Object o, String... m) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException {
if (o == null || m.length == 0) {
return null;
}
for (String m1 : m) {
o = o.getClass().getMethod(m1).invoke(o);
if (o == null) {
return null;
}
}
return o;
}
And call it like this:
Boolean source = (Boolean) get(registration, "getApplication", "getMetadata", "getSource");
return source == null ? false : !source;
But I wouldn't do it this way in any serious projects.
answered yesterday
Mika LammiMika Lammi
975619
2
This is bad code in so many aspects: slow, not controlled by the compiler, immune to refactoring aids from the IDE. Even you recognize that you wouldn't use this in any serious projects. But then: what's the point? No one would bother to post a question or even read the answers for unserious projects.
– julodnik
yesterday
It could become a bit better if you passed Methods as parameters instead of strings. It would probably look a bit likereturn Optional.of(registration).map(Registration::getApplication).map(Application::getMetadata).map(Metadata::getSource)so you might as well useOptionaldirectly. Still, I don't think you deserved downvotes. This method is still interesting as a thought experiment.
– Eric Duminil
yesterday
add a comment |
-1
You could do it using a hacky method like this:
public static Object get(Object o, String... m) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException {
if (o == null || m.length == 0) {
return null;
}
for (String m1 : m) {
o = o.getClass().getMethod(m1).invoke(o);
if (o == null) {
return null;
}
}
return o;
}
And call it like this:
Boolean source = (Boolean) get(registration, "getApplication", "getMetadata", "getSource");
return source == null ? false : !source;
But I wouldn't do it this way in any serious projects.
answered yesterday
Mika LammiMika Lammi
975619
2
This is bad code in so many aspects: slow, not controlled by the compiler, immune to refactoring aids from the IDE. Even you recognize that you wouldn't use this in any serious projects. But then: what's the point? No one would bother to post a question or even read the answers for unserious projects.
– julodnik
yesterday
It could become a bit better if you passed Methods as parameters instead of strings. It would probably look a bit likereturn Optional.of(registration).map(Registration::getApplication).map(Application::getMetadata).map(Metadata::getSource)so you might as well useOptionaldirectly. Still, I don't think you deserved downvotes. This method is still interesting as a thought experiment.
– Eric Duminil
yesterday
add a comment |
-1
-1
-1
You could do it using a hacky method like this:
public static Object get(Object o, String... m) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException {
if (o == null || m.length == 0) {
return null;
}
for (String m1 : m) {
o = o.getClass().getMethod(m1).invoke(o);
if (o == null) {
return null;
}
}
return o;
}
And call it like this:
Boolean source = (Boolean) get(registration, "getApplication", "getMetadata", "getSource");
return source == null ? false : !source;
But I wouldn't do it this way in any serious projects.
answered yesterday
Mika LammiMika Lammi
975619
You could do it using a hacky method like this:
public static Object get(Object o, String... m) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException {
if (o == null || m.length == 0) {
return null;
}
for (String m1 : m) {
o = o.getClass().getMethod(m1).invoke(o);
if (o == null) {
return null;
}
}
return o;
}
And call it like this:
Boolean source = (Boolean) get(registration, "getApplication", "getMetadata", "getSource");
return source == null ? false : !source;
But I wouldn't do it this way in any serious projects.
answered yesterday
Mika LammiMika Lammi
975619
edited yesterday
answered yesterday
Mika LammiMika Lammi
975619
answered yesterday
Mika LammiMika Lammi
975619
answered yesterday
Mika LammiMika Lammi
975619
975619
2
This is bad code in so many aspects: slow, not controlled by the compiler, immune to refactoring aids from the IDE. Even you recognize that you wouldn't use this in any serious projects. But then: what's the point? No one would bother to post a question or even read the answers for unserious projects.
– julodnik
yesterday
It could become a bit better if you passed Methods as parameters instead of strings. It would probably look a bit likereturn Optional.of(registration).map(Registration::getApplication).map(Application::getMetadata).map(Metadata::getSource)so you might as well useOptionaldirectly. Still, I don't think you deserved downvotes. This method is still interesting as a thought experiment.
– Eric Duminil
yesterday
add a comment |
2
This is bad code in so many aspects: slow, not controlled by the compiler, immune to refactoring aids from the IDE. Even you recognize that you wouldn't use this in any serious projects. But then: what's the point? No one would bother to post a question or even read the answers for unserious projects.
– julodnik
yesterday
It could become a bit better if you passed Methods as parameters instead of strings. It would probably look a bit likereturn Optional.of(registration).map(Registration::getApplication).map(Application::getMetadata).map(Metadata::getSource)so you might as well useOptionaldirectly. Still, I don't think you deserved downvotes. This method is still interesting as a thought experiment.
– Eric Duminil
yesterday
2
2
This is bad code in so many aspects: slow, not controlled by the compiler, immune to refactoring aids from the IDE. Even you recognize that you wouldn't use this in any serious projects. But then: what's the point? No one would bother to post a question or even read the answers for unserious projects.
– julodnik
yesterday
This is bad code in so many aspects: slow, not controlled by the compiler, immune to refactoring aids from the IDE. Even you recognize that you wouldn't use this in any serious projects. But then: what's the point? No one would bother to post a question or even read the answers for unserious projects.
– julodnik
yesterday
It could become a bit better if you passed Methods as parameters instead of strings. It would probably look a bit like
return Optional.of(registration).map(Registration::getApplication).map(Application::getMetadata).map(Metadata::getSource) so you might as well use Optional directly. Still, I don't think you deserved downvotes. This method is still interesting as a thought experiment.– Eric Duminil
yesterday
It could become a bit better if you passed Methods as parameters instead of strings. It would probably look a bit like
return Optional.of(registration).map(Registration::getApplication).map(Application::getMetadata).map(Metadata::getSource) so you might as well use Optional directly. Still, I don't think you deserved downvotes. This method is still interesting as a thought experiment.– Eric Duminil
yesterday
add a comment |
