JSON Schema Validation helper method

Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
This is what I wrote to validate JSON to the given schema.
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException
String errorMessage = null;
if (json != null)
if(jsonSchema == null)
errorMessage = "json exist in request but there is no schema to validate it against";
else
try
JsonSchema jsonSchema = JsonSchemaFactory.byDefault().getJsonSchema(jsonSchema);
ProcessingReport processingReport = jsonSchema.validate(json);
if (!processingReport.isSuccess())
StringBuilder sb = new StringBuilder();
processingReport.forEach(jsonError -> sb.append(String.format("[%s] ", jsonError)));
errorMessage = String.format("json validation failed. Errors: %s", sb.toString());
catch (ProcessingException e)
errorMessage = String.format("json validation threw ProcessingException. Error Message: %s", e.getMessage());
if (errorMessage != null)
throw new InvalidRequestException(errorMessage);
Here are few things that I had in my mind while writing this code:
I don't want to return anything from the method. Schema is either
validorinvalid. In case ofinvalid, I just throw an exception. Since it's part of aHelperclass, I think it's okay to put some business logic (throwing exception) with in this code.I like 1 point of return or 1 point of exception throwing. Thats why I am using
errorMessageto capture any error and if it exists, throw it at the end. By this approach, the code readability is much better.The
jsonSchemaandjsonboth are optional. In case ifjsondoesn't exist, there is no point of getting into validation.
java json validation helper
bumped to the homepage by Community⦠2 days ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |Â
up vote
3
down vote
favorite
This is what I wrote to validate JSON to the given schema.
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException
String errorMessage = null;
if (json != null)
if(jsonSchema == null)
errorMessage = "json exist in request but there is no schema to validate it against";
else
try
JsonSchema jsonSchema = JsonSchemaFactory.byDefault().getJsonSchema(jsonSchema);
ProcessingReport processingReport = jsonSchema.validate(json);
if (!processingReport.isSuccess())
StringBuilder sb = new StringBuilder();
processingReport.forEach(jsonError -> sb.append(String.format("[%s] ", jsonError)));
errorMessage = String.format("json validation failed. Errors: %s", sb.toString());
catch (ProcessingException e)
errorMessage = String.format("json validation threw ProcessingException. Error Message: %s", e.getMessage());
if (errorMessage != null)
throw new InvalidRequestException(errorMessage);
Here are few things that I had in my mind while writing this code:
I don't want to return anything from the method. Schema is either
validorinvalid. In case ofinvalid, I just throw an exception. Since it's part of aHelperclass, I think it's okay to put some business logic (throwing exception) with in this code.I like 1 point of return or 1 point of exception throwing. Thats why I am using
errorMessageto capture any error and if it exists, throw it at the end. By this approach, the code readability is much better.The
jsonSchemaandjsonboth are optional. In case ifjsondoesn't exist, there is no point of getting into validation.
java json validation helper
bumped to the homepage by Community⦠2 days ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
This is what I wrote to validate JSON to the given schema.
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException
String errorMessage = null;
if (json != null)
if(jsonSchema == null)
errorMessage = "json exist in request but there is no schema to validate it against";
else
try
JsonSchema jsonSchema = JsonSchemaFactory.byDefault().getJsonSchema(jsonSchema);
ProcessingReport processingReport = jsonSchema.validate(json);
if (!processingReport.isSuccess())
StringBuilder sb = new StringBuilder();
processingReport.forEach(jsonError -> sb.append(String.format("[%s] ", jsonError)));
errorMessage = String.format("json validation failed. Errors: %s", sb.toString());
catch (ProcessingException e)
errorMessage = String.format("json validation threw ProcessingException. Error Message: %s", e.getMessage());
if (errorMessage != null)
throw new InvalidRequestException(errorMessage);
Here are few things that I had in my mind while writing this code:
I don't want to return anything from the method. Schema is either
validorinvalid. In case ofinvalid, I just throw an exception. Since it's part of aHelperclass, I think it's okay to put some business logic (throwing exception) with in this code.I like 1 point of return or 1 point of exception throwing. Thats why I am using
errorMessageto capture any error and if it exists, throw it at the end. By this approach, the code readability is much better.The
jsonSchemaandjsonboth are optional. In case ifjsondoesn't exist, there is no point of getting into validation.
java json validation helper
This is what I wrote to validate JSON to the given schema.
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException
String errorMessage = null;
if (json != null)
if(jsonSchema == null)
errorMessage = "json exist in request but there is no schema to validate it against";
else
try
JsonSchema jsonSchema = JsonSchemaFactory.byDefault().getJsonSchema(jsonSchema);
ProcessingReport processingReport = jsonSchema.validate(json);
if (!processingReport.isSuccess())
StringBuilder sb = new StringBuilder();
processingReport.forEach(jsonError -> sb.append(String.format("[%s] ", jsonError)));
errorMessage = String.format("json validation failed. Errors: %s", sb.toString());
catch (ProcessingException e)
errorMessage = String.format("json validation threw ProcessingException. Error Message: %s", e.getMessage());
if (errorMessage != null)
throw new InvalidRequestException(errorMessage);
Here are few things that I had in my mind while writing this code:
I don't want to return anything from the method. Schema is either
validorinvalid. In case ofinvalid, I just throw an exception. Since it's part of aHelperclass, I think it's okay to put some business logic (throwing exception) with in this code.I like 1 point of return or 1 point of exception throwing. Thats why I am using
errorMessageto capture any error and if it exists, throw it at the end. By this approach, the code readability is much better.The
jsonSchemaandjsonboth are optional. In case ifjsondoesn't exist, there is no point of getting into validation.
java json validation helper
edited Jan 18 at 19:59
Sam Onela
5,88461545
5,88461545
asked Jan 18 at 18:25
Em Ae
19317
19317
bumped to the homepage by Community⦠2 days ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community⦠2 days ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
0
down vote
You wrote a bullet list so I try to comment each bullet separately
I have mixed sentiment about this. I do agree with this stack overflow post, I'll quote
An exception is thrown when a fundamental assumption of the current code block is found to be false.
Here you want to validate a Json schema, so your code validate it or not, but if the parameter for JsonSchema is
nullit goes contrary to what is expected so I believe you are right to throw the exception.But for the same reason, I believe you should not return an exception when
processingReport.isSuccess()returns false. My take on this would be to returntrueoffalseto indicate if validation is ok or not. That might have to do with personal taste.I like it the same way, but sometimes it's good to throw an exception as soon as you can. Here I it doesn't really matter, your code is readable and understandable, do as you please.
I see nothing wrong with the fact that if
jsonisnullyou don't check forjsonSchema. The only thing maybe I would be wary of is because you don't return a value, you considerjson == nullthe same as a validjson, which might be a bit confusing.
thanks for the input. Regarding point 1. If i returntrueorfalsei would nee a mechanism to let callee know what were json errors. In my case, i need to tell clients that json was invalid because of these errors. thats why i am building an error message and throwing an exception which contains those errors. regarding 3: This is correct assumption. Since ifjsonis null, the rest of the business logic should continue. thejsonis an optional parameter to api. so a null json means that there were no validation errros so we can continue to process remaining request.
â Em Ae
Jan 18 at 20:03
Maybe you could return an object containing abooleanfor knowing if validation istrueorfalseand a list of error if needed? This way exception would be thrown only when something exceptional happen, as I believe they should be. Or maybe an another way of returning your errors without using exception? (Your solution is fine, I'm nitpicking a bit since you asked a review ;) )
â Julien Rousé
Jan 18 at 20:14
add a comment |Â
up vote
0
down vote
Contrary to Julien Rousé and you, I'm rather against the "1 point of return" policy. It doesn't make it more readable. It might make it a bit easier to formally prove correctness of the code, but I have never seen someone do that outside of an academic context.
As it is now, when looking at what would happen if the json == null you'd first encounter the if(json != null) line. Then you scroll down 20 or more lines to find the end of that if block finding that there's no else block. But the method doesn't end here yet. There's another if (message != null) line where I forgot if I had encountered any initialisation in the meantime so I have to go over the entire method again to see if it is null or not ...
Compare that with a method that starts with:
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException {
if (json == null)
return;
By writing in this "return as early as possible" style, you immediatly see that empty json objects are always valid. If at some point it's clear what the result of the method should be, then I want that to be clear explicitly at that point. I don't want to tire myself constantly looking up and down the method to see if I didn't miss anything (for example: was this message really still null when we got here?).
That's why I would prefer to structure the method like this:
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException
if (json == null)
return;
if(jsonSchema == null)
throw new InvalidRequestException("json exist in request but there is no schema to validate it against");
try
JsonSchema jsonSchema = JsonSchemaFactory.byDefault().getJsonSchema(jsonSchema);
ProcessingReport processingReport = jsonSchema.validate(json);
if (!processingReport.isSuccess())
StringBuilder sb = new StringBuilder();
processingReport.forEach(jsonError -> sb.append(String.format("[%s] ", jsonError)));
throw new InvalidRequestException(String.format("json validation failed. Errors: %s", sb.toString()));
catch (ProcessingException e)
throw new InvalidRequestException(String.format("json validation threw ProcessingException. Error Message: %s", e.getMessage()));
I'd say this is more readable and especially easier to find out what the result is of the special cases. Not that I had any trouble reading/understanding your code ofcourse. I just prefer the way that takes a little bit less effort to understand completely.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
You wrote a bullet list so I try to comment each bullet separately
I have mixed sentiment about this. I do agree with this stack overflow post, I'll quote
An exception is thrown when a fundamental assumption of the current code block is found to be false.
Here you want to validate a Json schema, so your code validate it or not, but if the parameter for JsonSchema is
nullit goes contrary to what is expected so I believe you are right to throw the exception.But for the same reason, I believe you should not return an exception when
processingReport.isSuccess()returns false. My take on this would be to returntrueoffalseto indicate if validation is ok or not. That might have to do with personal taste.I like it the same way, but sometimes it's good to throw an exception as soon as you can. Here I it doesn't really matter, your code is readable and understandable, do as you please.
I see nothing wrong with the fact that if
jsonisnullyou don't check forjsonSchema. The only thing maybe I would be wary of is because you don't return a value, you considerjson == nullthe same as a validjson, which might be a bit confusing.
thanks for the input. Regarding point 1. If i returntrueorfalsei would nee a mechanism to let callee know what were json errors. In my case, i need to tell clients that json was invalid because of these errors. thats why i am building an error message and throwing an exception which contains those errors. regarding 3: This is correct assumption. Since ifjsonis null, the rest of the business logic should continue. thejsonis an optional parameter to api. so a null json means that there were no validation errros so we can continue to process remaining request.
â Em Ae
Jan 18 at 20:03
Maybe you could return an object containing abooleanfor knowing if validation istrueorfalseand a list of error if needed? This way exception would be thrown only when something exceptional happen, as I believe they should be. Or maybe an another way of returning your errors without using exception? (Your solution is fine, I'm nitpicking a bit since you asked a review ;) )
â Julien Rousé
Jan 18 at 20:14
add a comment |Â
up vote
0
down vote
You wrote a bullet list so I try to comment each bullet separately
I have mixed sentiment about this. I do agree with this stack overflow post, I'll quote
An exception is thrown when a fundamental assumption of the current code block is found to be false.
Here you want to validate a Json schema, so your code validate it or not, but if the parameter for JsonSchema is
nullit goes contrary to what is expected so I believe you are right to throw the exception.But for the same reason, I believe you should not return an exception when
processingReport.isSuccess()returns false. My take on this would be to returntrueoffalseto indicate if validation is ok or not. That might have to do with personal taste.I like it the same way, but sometimes it's good to throw an exception as soon as you can. Here I it doesn't really matter, your code is readable and understandable, do as you please.
I see nothing wrong with the fact that if
jsonisnullyou don't check forjsonSchema. The only thing maybe I would be wary of is because you don't return a value, you considerjson == nullthe same as a validjson, which might be a bit confusing.
thanks for the input. Regarding point 1. If i returntrueorfalsei would nee a mechanism to let callee know what were json errors. In my case, i need to tell clients that json was invalid because of these errors. thats why i am building an error message and throwing an exception which contains those errors. regarding 3: This is correct assumption. Since ifjsonis null, the rest of the business logic should continue. thejsonis an optional parameter to api. so a null json means that there were no validation errros so we can continue to process remaining request.
â Em Ae
Jan 18 at 20:03
Maybe you could return an object containing abooleanfor knowing if validation istrueorfalseand a list of error if needed? This way exception would be thrown only when something exceptional happen, as I believe they should be. Or maybe an another way of returning your errors without using exception? (Your solution is fine, I'm nitpicking a bit since you asked a review ;) )
â Julien Rousé
Jan 18 at 20:14
add a comment |Â
up vote
0
down vote
up vote
0
down vote
You wrote a bullet list so I try to comment each bullet separately
I have mixed sentiment about this. I do agree with this stack overflow post, I'll quote
An exception is thrown when a fundamental assumption of the current code block is found to be false.
Here you want to validate a Json schema, so your code validate it or not, but if the parameter for JsonSchema is
nullit goes contrary to what is expected so I believe you are right to throw the exception.But for the same reason, I believe you should not return an exception when
processingReport.isSuccess()returns false. My take on this would be to returntrueoffalseto indicate if validation is ok or not. That might have to do with personal taste.I like it the same way, but sometimes it's good to throw an exception as soon as you can. Here I it doesn't really matter, your code is readable and understandable, do as you please.
I see nothing wrong with the fact that if
jsonisnullyou don't check forjsonSchema. The only thing maybe I would be wary of is because you don't return a value, you considerjson == nullthe same as a validjson, which might be a bit confusing.
You wrote a bullet list so I try to comment each bullet separately
I have mixed sentiment about this. I do agree with this stack overflow post, I'll quote
An exception is thrown when a fundamental assumption of the current code block is found to be false.
Here you want to validate a Json schema, so your code validate it or not, but if the parameter for JsonSchema is
nullit goes contrary to what is expected so I believe you are right to throw the exception.But for the same reason, I believe you should not return an exception when
processingReport.isSuccess()returns false. My take on this would be to returntrueoffalseto indicate if validation is ok or not. That might have to do with personal taste.I like it the same way, but sometimes it's good to throw an exception as soon as you can. Here I it doesn't really matter, your code is readable and understandable, do as you please.
I see nothing wrong with the fact that if
jsonisnullyou don't check forjsonSchema. The only thing maybe I would be wary of is because you don't return a value, you considerjson == nullthe same as a validjson, which might be a bit confusing.
edited Jan 19 at 11:49
answered Jan 18 at 19:58
Julien Rousé
446416
446416
thanks for the input. Regarding point 1. If i returntrueorfalsei would nee a mechanism to let callee know what were json errors. In my case, i need to tell clients that json was invalid because of these errors. thats why i am building an error message and throwing an exception which contains those errors. regarding 3: This is correct assumption. Since ifjsonis null, the rest of the business logic should continue. thejsonis an optional parameter to api. so a null json means that there were no validation errros so we can continue to process remaining request.
â Em Ae
Jan 18 at 20:03
Maybe you could return an object containing abooleanfor knowing if validation istrueorfalseand a list of error if needed? This way exception would be thrown only when something exceptional happen, as I believe they should be. Or maybe an another way of returning your errors without using exception? (Your solution is fine, I'm nitpicking a bit since you asked a review ;) )
â Julien Rousé
Jan 18 at 20:14
add a comment |Â
thanks for the input. Regarding point 1. If i returntrueorfalsei would nee a mechanism to let callee know what were json errors. In my case, i need to tell clients that json was invalid because of these errors. thats why i am building an error message and throwing an exception which contains those errors. regarding 3: This is correct assumption. Since ifjsonis null, the rest of the business logic should continue. thejsonis an optional parameter to api. so a null json means that there were no validation errros so we can continue to process remaining request.
â Em Ae
Jan 18 at 20:03
Maybe you could return an object containing abooleanfor knowing if validation istrueorfalseand a list of error if needed? This way exception would be thrown only when something exceptional happen, as I believe they should be. Or maybe an another way of returning your errors without using exception? (Your solution is fine, I'm nitpicking a bit since you asked a review ;) )
â Julien Rousé
Jan 18 at 20:14
thanks for the input. Regarding point 1. If i return
true or false i would nee a mechanism to let callee know what were json errors. In my case, i need to tell clients that json was invalid because of these errors. thats why i am building an error message and throwing an exception which contains those errors. regarding 3: This is correct assumption. Since if json is null, the rest of the business logic should continue. the json is an optional parameter to api. so a null json means that there were no validation errros so we can continue to process remaining request.â Em Ae
Jan 18 at 20:03
thanks for the input. Regarding point 1. If i return
true or false i would nee a mechanism to let callee know what were json errors. In my case, i need to tell clients that json was invalid because of these errors. thats why i am building an error message and throwing an exception which contains those errors. regarding 3: This is correct assumption. Since if json is null, the rest of the business logic should continue. the json is an optional parameter to api. so a null json means that there were no validation errros so we can continue to process remaining request.â Em Ae
Jan 18 at 20:03
Maybe you could return an object containing a
boolean for knowing if validation is true or false and a list of error if needed? This way exception would be thrown only when something exceptional happen, as I believe they should be. Or maybe an another way of returning your errors without using exception? (Your solution is fine, I'm nitpicking a bit since you asked a review ;) )â Julien Rousé
Jan 18 at 20:14
Maybe you could return an object containing a
boolean for knowing if validation is true or false and a list of error if needed? This way exception would be thrown only when something exceptional happen, as I believe they should be. Or maybe an another way of returning your errors without using exception? (Your solution is fine, I'm nitpicking a bit since you asked a review ;) )â Julien Rousé
Jan 18 at 20:14
add a comment |Â
up vote
0
down vote
Contrary to Julien Rousé and you, I'm rather against the "1 point of return" policy. It doesn't make it more readable. It might make it a bit easier to formally prove correctness of the code, but I have never seen someone do that outside of an academic context.
As it is now, when looking at what would happen if the json == null you'd first encounter the if(json != null) line. Then you scroll down 20 or more lines to find the end of that if block finding that there's no else block. But the method doesn't end here yet. There's another if (message != null) line where I forgot if I had encountered any initialisation in the meantime so I have to go over the entire method again to see if it is null or not ...
Compare that with a method that starts with:
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException {
if (json == null)
return;
By writing in this "return as early as possible" style, you immediatly see that empty json objects are always valid. If at some point it's clear what the result of the method should be, then I want that to be clear explicitly at that point. I don't want to tire myself constantly looking up and down the method to see if I didn't miss anything (for example: was this message really still null when we got here?).
That's why I would prefer to structure the method like this:
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException
if (json == null)
return;
if(jsonSchema == null)
throw new InvalidRequestException("json exist in request but there is no schema to validate it against");
try
JsonSchema jsonSchema = JsonSchemaFactory.byDefault().getJsonSchema(jsonSchema);
ProcessingReport processingReport = jsonSchema.validate(json);
if (!processingReport.isSuccess())
StringBuilder sb = new StringBuilder();
processingReport.forEach(jsonError -> sb.append(String.format("[%s] ", jsonError)));
throw new InvalidRequestException(String.format("json validation failed. Errors: %s", sb.toString()));
catch (ProcessingException e)
throw new InvalidRequestException(String.format("json validation threw ProcessingException. Error Message: %s", e.getMessage()));
I'd say this is more readable and especially easier to find out what the result is of the special cases. Not that I had any trouble reading/understanding your code ofcourse. I just prefer the way that takes a little bit less effort to understand completely.
add a comment |Â
up vote
0
down vote
Contrary to Julien Rousé and you, I'm rather against the "1 point of return" policy. It doesn't make it more readable. It might make it a bit easier to formally prove correctness of the code, but I have never seen someone do that outside of an academic context.
As it is now, when looking at what would happen if the json == null you'd first encounter the if(json != null) line. Then you scroll down 20 or more lines to find the end of that if block finding that there's no else block. But the method doesn't end here yet. There's another if (message != null) line where I forgot if I had encountered any initialisation in the meantime so I have to go over the entire method again to see if it is null or not ...
Compare that with a method that starts with:
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException {
if (json == null)
return;
By writing in this "return as early as possible" style, you immediatly see that empty json objects are always valid. If at some point it's clear what the result of the method should be, then I want that to be clear explicitly at that point. I don't want to tire myself constantly looking up and down the method to see if I didn't miss anything (for example: was this message really still null when we got here?).
That's why I would prefer to structure the method like this:
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException
if (json == null)
return;
if(jsonSchema == null)
throw new InvalidRequestException("json exist in request but there is no schema to validate it against");
try
JsonSchema jsonSchema = JsonSchemaFactory.byDefault().getJsonSchema(jsonSchema);
ProcessingReport processingReport = jsonSchema.validate(json);
if (!processingReport.isSuccess())
StringBuilder sb = new StringBuilder();
processingReport.forEach(jsonError -> sb.append(String.format("[%s] ", jsonError)));
throw new InvalidRequestException(String.format("json validation failed. Errors: %s", sb.toString()));
catch (ProcessingException e)
throw new InvalidRequestException(String.format("json validation threw ProcessingException. Error Message: %s", e.getMessage()));
I'd say this is more readable and especially easier to find out what the result is of the special cases. Not that I had any trouble reading/understanding your code ofcourse. I just prefer the way that takes a little bit less effort to understand completely.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Contrary to Julien Rousé and you, I'm rather against the "1 point of return" policy. It doesn't make it more readable. It might make it a bit easier to formally prove correctness of the code, but I have never seen someone do that outside of an academic context.
As it is now, when looking at what would happen if the json == null you'd first encounter the if(json != null) line. Then you scroll down 20 or more lines to find the end of that if block finding that there's no else block. But the method doesn't end here yet. There's another if (message != null) line where I forgot if I had encountered any initialisation in the meantime so I have to go over the entire method again to see if it is null or not ...
Compare that with a method that starts with:
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException {
if (json == null)
return;
By writing in this "return as early as possible" style, you immediatly see that empty json objects are always valid. If at some point it's clear what the result of the method should be, then I want that to be clear explicitly at that point. I don't want to tire myself constantly looking up and down the method to see if I didn't miss anything (for example: was this message really still null when we got here?).
That's why I would prefer to structure the method like this:
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException
if (json == null)
return;
if(jsonSchema == null)
throw new InvalidRequestException("json exist in request but there is no schema to validate it against");
try
JsonSchema jsonSchema = JsonSchemaFactory.byDefault().getJsonSchema(jsonSchema);
ProcessingReport processingReport = jsonSchema.validate(json);
if (!processingReport.isSuccess())
StringBuilder sb = new StringBuilder();
processingReport.forEach(jsonError -> sb.append(String.format("[%s] ", jsonError)));
throw new InvalidRequestException(String.format("json validation failed. Errors: %s", sb.toString()));
catch (ProcessingException e)
throw new InvalidRequestException(String.format("json validation threw ProcessingException. Error Message: %s", e.getMessage()));
I'd say this is more readable and especially easier to find out what the result is of the special cases. Not that I had any trouble reading/understanding your code ofcourse. I just prefer the way that takes a little bit less effort to understand completely.
Contrary to Julien Rousé and you, I'm rather against the "1 point of return" policy. It doesn't make it more readable. It might make it a bit easier to formally prove correctness of the code, but I have never seen someone do that outside of an academic context.
As it is now, when looking at what would happen if the json == null you'd first encounter the if(json != null) line. Then you scroll down 20 or more lines to find the end of that if block finding that there's no else block. But the method doesn't end here yet. There's another if (message != null) line where I forgot if I had encountered any initialisation in the meantime so I have to go over the entire method again to see if it is null or not ...
Compare that with a method that starts with:
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException {
if (json == null)
return;
By writing in this "return as early as possible" style, you immediatly see that empty json objects are always valid. If at some point it's clear what the result of the method should be, then I want that to be clear explicitly at that point. I don't want to tire myself constantly looking up and down the method to see if I didn't miss anything (for example: was this message really still null when we got here?).
That's why I would prefer to structure the method like this:
public void validateJsonSchema(ObjectNode jsonSchema, ObjectNode json) throws InvalidRequestException
if (json == null)
return;
if(jsonSchema == null)
throw new InvalidRequestException("json exist in request but there is no schema to validate it against");
try
JsonSchema jsonSchema = JsonSchemaFactory.byDefault().getJsonSchema(jsonSchema);
ProcessingReport processingReport = jsonSchema.validate(json);
if (!processingReport.isSuccess())
StringBuilder sb = new StringBuilder();
processingReport.forEach(jsonError -> sb.append(String.format("[%s] ", jsonError)));
throw new InvalidRequestException(String.format("json validation failed. Errors: %s", sb.toString()));
catch (ProcessingException e)
throw new InvalidRequestException(String.format("json validation threw ProcessingException. Error Message: %s", e.getMessage()));
I'd say this is more readable and especially easier to find out what the result is of the special cases. Not that I had any trouble reading/understanding your code ofcourse. I just prefer the way that takes a little bit less effort to understand completely.
answered Jan 19 at 13:09
Imus
3,328223
3,328223
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f185419%2fjson-schema-validation-helper-method%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password