debugjavaMinor
Is it good practice in Java to pass a StringBuffer to a method to get error messages
Viewed 0 times
errormethodpasspracticejavagetmessagesgoodstringbuffer
Problem
I have a class that has a method which takes a user as an argument and performs several validation checks on the user and returns a boolean to indicate if theyare valid.
I want to be able to get error messages back from the validation method along with the boolean return value.
I was thinking of doing it by passing a StringBuffer as an argument along with the user and in the validation code appending error messages to the buffer so that the caller gets the boolean returned and then can look at the StringBuffer for error messages.
Is this good practice in Java? Or would it be better to log the errors to a buffer in the validation class and have a public method to get the errors? Or should the validateUser() method return an object that contains the boolean and errors?
Thank you!
I want to be able to get error messages back from the validation method along with the boolean return value.
I was thinking of doing it by passing a StringBuffer as an argument along with the user and in the validation code appending error messages to the buffer so that the caller gets the boolean returned and then can look at the StringBuffer for error messages.
// validation class
public boolean validateUser(User user, StringBuffer errors) {
...
}
// caller
StringBuffer errors = new StringBuffer();
boolean validUser = validateUser(user, errors);
if (!validUser) {
log(errors.toString();
}Is this good practice in Java? Or would it be better to log the errors to a buffer in the validation class and have a public method to get the errors? Or should the validateUser() method return an object that contains the boolean and errors?
Thank you!
Solution
Since you are dealing with a validation method, I believe you will want to read my question Is it better practice to have void method throw an exception or to have the method return a boolean? and its answers. My point there is that you don't really need to return a boolean, you could also have a void method throw an exception if the validation fails. The exception could then, in your case, contain the errors as its payload. But I think that passing a logger as a parameter isn't a bad practice, just basically a matter of personal preference and to be decided on a case by case basis, much like the question about whether to return a boolean or to throw an exception.
In any case, however, I would never use a StringBuffer as an error logger like in your case. For one, I might be building a web application where the output is rendered in HTML. In that case the StringBuffer would basically need to contain the HTML markup, which would then become a problem once you one day figure out that you need to run your process from the command line as well, and then you get all the HTML markup to mess up the output there. Also, with the StringBuffer you cannot easily get the error count, just whether there were any errors or not. So I would probably create an implementation of some IErrorHandler kind of interface wrapping a
In any case, however, I would never use a StringBuffer as an error logger like in your case. For one, I might be building a web application where the output is rendered in HTML. In that case the StringBuffer would basically need to contain the HTML markup, which would then become a problem once you one day figure out that you need to run your process from the command line as well, and then you get all the HTML markup to mess up the output there. Also, with the StringBuffer you cannot easily get the error count, just whether there were any errors or not. So I would probably create an implementation of some IErrorHandler kind of interface wrapping a
List rather than a StringBuffer, as in @dreza's answer.Context
StackExchange Code Review Q#18671, answer score: 5
Revisions (0)
No revisions yet.