returning error string or null for “no errors” [on hold]
up vote
-1
down vote
favorite
In my code I have several validation methods which have common part. I extracted common part into dedicated method and now code looks like this:
public String validate1() {
String common = validateCommon();
if (common != null) {
return common;
}
// do something
return something1;
}
public String validate2() {
String common = validateCommon();
if (common != null) {
return common;
}
// do something
return something2;
}
public String validateCommon() {
...
}
I don't like how null
has special meaning of "no errors occured`. May be I can refactor to something like this:
public String validate1() {
return validateCommon().orElseGet(() -> {
// do something
return something1;
});
}
public Optional<String> validateCommon() {
...
}
But this doesn't look beautiful too, because "normal" code is under orElseGet
, but error processing is at the beginning of the method, this looks odd.
Can I refactor it to something more readable?
java
put on hold as off-topic by vnp, Sᴀᴍ Onᴇᴌᴀ, 200_success, Heslacher, t3chb0t yesterday
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – vnp, Sᴀᴍ Onᴇᴌᴀ, 200_success, Heslacher, t3chb0t
If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
up vote
-1
down vote
favorite
In my code I have several validation methods which have common part. I extracted common part into dedicated method and now code looks like this:
public String validate1() {
String common = validateCommon();
if (common != null) {
return common;
}
// do something
return something1;
}
public String validate2() {
String common = validateCommon();
if (common != null) {
return common;
}
// do something
return something2;
}
public String validateCommon() {
...
}
I don't like how null
has special meaning of "no errors occured`. May be I can refactor to something like this:
public String validate1() {
return validateCommon().orElseGet(() -> {
// do something
return something1;
});
}
public Optional<String> validateCommon() {
...
}
But this doesn't look beautiful too, because "normal" code is under orElseGet
, but error processing is at the beginning of the method, this looks odd.
Can I refactor it to something more readable?
java
put on hold as off-topic by vnp, Sᴀᴍ Onᴇᴌᴀ, 200_success, Heslacher, t3chb0t yesterday
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – vnp, Sᴀᴍ Onᴇᴌᴀ, 200_success, Heslacher, t3chb0t
If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
In my code I have several validation methods which have common part. I extracted common part into dedicated method and now code looks like this:
public String validate1() {
String common = validateCommon();
if (common != null) {
return common;
}
// do something
return something1;
}
public String validate2() {
String common = validateCommon();
if (common != null) {
return common;
}
// do something
return something2;
}
public String validateCommon() {
...
}
I don't like how null
has special meaning of "no errors occured`. May be I can refactor to something like this:
public String validate1() {
return validateCommon().orElseGet(() -> {
// do something
return something1;
});
}
public Optional<String> validateCommon() {
...
}
But this doesn't look beautiful too, because "normal" code is under orElseGet
, but error processing is at the beginning of the method, this looks odd.
Can I refactor it to something more readable?
java
In my code I have several validation methods which have common part. I extracted common part into dedicated method and now code looks like this:
public String validate1() {
String common = validateCommon();
if (common != null) {
return common;
}
// do something
return something1;
}
public String validate2() {
String common = validateCommon();
if (common != null) {
return common;
}
// do something
return something2;
}
public String validateCommon() {
...
}
I don't like how null
has special meaning of "no errors occured`. May be I can refactor to something like this:
public String validate1() {
return validateCommon().orElseGet(() -> {
// do something
return something1;
});
}
public Optional<String> validateCommon() {
...
}
But this doesn't look beautiful too, because "normal" code is under orElseGet
, but error processing is at the beginning of the method, this looks odd.
Can I refactor it to something more readable?
java
java
asked 2 days ago
javapowered
2694722
2694722
put on hold as off-topic by vnp, Sᴀᴍ Onᴇᴌᴀ, 200_success, Heslacher, t3chb0t yesterday
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – vnp, Sᴀᴍ Onᴇᴌᴀ, 200_success, Heslacher, t3chb0t
If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as off-topic by vnp, Sᴀᴍ Onᴇᴌᴀ, 200_success, Heslacher, t3chb0t yesterday
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – vnp, Sᴀᴍ Onᴇᴌᴀ, 200_success, Heslacher, t3chb0t
If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes