Enum Idiom Question
in [Java Programming]
|
From: Jeff Higgins on 28 May 2010 23:32 On 5/28/2010 11:05 PM, Jeff Higgins wrote: > On 5/28/2010 8:54 PM, Rhino wrote: >> "Jeff Higgins"<oohiggins(a)yahoo.com> wrote in message >> news:htpioj$rau$1(a)news.eternal-september.org... >>> On 5/28/2010 7:02 PM, Rhino wrote: > >> >> What do you think? Is PadResult or something like it my best alternative >> here, assuming we agree that an exception is overkill for a case where an >> input parameter is just miscoded? > > I'd just throw an StringUtilsException > if I couldn't recover from an illegal argument. > If you need to go all I18N happy use a MessageFormat. > > try { > StringUtils.pad() > } catch(StringUtilsException e) { > HandleException(LocalizeExceptionMessage(e)) > } > I may be wrong but I don't think that the Apache StringUtils.rightPad() method throws any exceptions. It just lets the callers deal with verifying their arguments. import org.apache.commons.lang.StringUtils; public class Scratch { public static void main(String[] args) { System.out.println(StringUtils.rightPad("Footsy", -1, ' ')); } } Yep, prints: Footsy
From: Jean-Baptiste Nizet on 29 May 2010 10:16 Rhino a �crit : >> I would seriously consider instead of the enum to have a boolean >> plus a String, because true/false and a textual explanation is >> really what you need. >> > Sorry, I meant to comment on this point too and didn't realize I had missed > it right away.... > > My little PadResult class started out with a boolean and a string with the > boolean indicating success or failure of the method and the string > containing either an error message or the padded version of the input > string. But when I looked at the invocation of PadResult and saw > > PadResult padResult = new PadResult(true, paddedString); > > or > > PadResult padResult = new PadResult(false, errorMsg); > > I found myself a bit challenged to remember if "true" meant "true, the > method produced a good result" or "true, the method found an error". I could > probably just memorize that true means a successful result or use some > boolean constants to make it clearer - see the example below - but I thought > it would be clearer still if I used a well-named enum value so I went with > the enum. When a constructor's argument are not sufficiently clear, it might be a good idea to use a factory method instead: public class PadResult { private String result; private String errorMessage; private boolean successful; private PadResult(boolean successful, String resultOrErrorMessage) { this.successful = successful; if (successful) { this.result = resultOrErrorMessage; } else { this.errorMessage = resultOrErrorMessage; } } public static PadResult createSuccessfulResult(String result) { return new PadResult(true, result); } public static PadResult createFailedResult(String errorMessage) { return new PadResult(false, errorMessage); } // getters omitted } then your pad() method uses return PadResult.createSuccessfulResult(result); or return PadResult.createFailedResult(errorMessage); and it's much clearer. JB.
From: Rhino on 29 May 2010 16:20 "Jeff Higgins" <oohiggins(a)yahoo.com> wrote in message news:htq0bq$gev$1(a)news.eternal-september.org... > On 5/28/2010 8:54 PM, Rhino wrote: >> "Jeff Higgins"<oohiggins(a)yahoo.com> wrote in message >> news:htpioj$rau$1(a)news.eternal-september.org... >>> On 5/28/2010 7:02 PM, Rhino wrote: > >> >> What do you think? Is PadResult or something like it my best alternative >> here, assuming we agree that an exception is overkill for a case where an >> input parameter is just miscoded? > > I'd just throw an StringUtilsException > if I couldn't recover from an illegal argument. > If you need to go all I18N happy use a MessageFormat. > > try { > StringUtils.pad() > } catch(StringUtilsException e) { > HandleException(LocalizeExceptionMessage(e)) > } > Fair enough. I'm just looking for alternatives to throwing an exception to see which approach I like best. There seems to be a considerably body of opinion that Exceptions are overkill for relatively minor things like bad input parameters and that they should be reserved for more severe problems. I'm trying to keep an open mind on the issue for now.... -- Rhino
From: Rhino on 29 May 2010 16:30 "Jeff Higgins" <oohiggins(a)yahoo.com> wrote in message news:htq1tg$lgj$1(a)news.eternal-september.org... > On 5/28/2010 11:05 PM, Jeff Higgins wrote: >> On 5/28/2010 8:54 PM, Rhino wrote: >>> "Jeff Higgins"<oohiggins(a)yahoo.com> wrote in message >>> news:htpioj$rau$1(a)news.eternal-september.org... >>>> On 5/28/2010 7:02 PM, Rhino wrote: >> >>> >>> What do you think? Is PadResult or something like it my best alternative >>> here, assuming we agree that an exception is overkill for a case where >>> an >>> input parameter is just miscoded? >> >> I'd just throw an StringUtilsException >> if I couldn't recover from an illegal argument. >> If you need to go all I18N happy use a MessageFormat. >> >> try { >> StringUtils.pad() >> } catch(StringUtilsException e) { >> HandleException(LocalizeExceptionMessage(e)) >> } >> > I may be wrong but I don't think that the Apache > StringUtils.rightPad() method throws any exceptions. > It just lets the callers deal with verifying their arguments. > > import org.apache.commons.lang.StringUtils; > > public class Scratch { > > public static void main(String[] args) { > System.out.println(StringUtils.rightPad("Footsy", -1, ' ')); > } > > } > > Yep, prints: > Footsy > I'm really not that concerned with padding per se. I just worked with a pad method for the purposes of exploring options other than exceptions for handling bad input to a method. Your specific point _is_ interesting though. I had already thought about making methods "failproof" by just ignoring bad input and making some sort of assumption about how they should behave if the input is bad. The rightPad() method you describe seems to be doing exactly that: if the final length of the string - I'm guessing that is what the second parameter is in rightPad() -you could simply ignore it altogether and do something arbitrary like pretending the user wanted the final length to be the same as the original length. I can see where that might be reasonable behaviour in some people's eyes for some methods. I'm not sure I buy it for a pad() method though. My feeling is that the person who is trying to use pad() (or rightPad() as the case may be) had SOMETHING in mind, even if he expressed it in a way that isn't logical for the method, like asking for a padded string to have a final length of -1. Now, the method could "second-guess"/reinterpret what he meant and, in some cases, it might even guess correctly. But it will surely guess incorrectly a lot of the time too. I would rather notify the user that the input didn't make sense so that he could ask for something that does make sense that guess and probably guess wrongly. Obviously, other developers may feel differently and prefer that the method make educated guesses about what the user meant, rather than sending him an error message. I'm fine with that. -- Rhino
From: Rhino on 29 May 2010 16:33
"Lew" <noone(a)lewscanon.com> wrote in message news:htq1jg$4mk$2(a)news.albasani.net... > Rhino wrote: >>> Okay, that's fair. But am I writing the comparison correctly? That == >>> operator looks wrong somehow, even if it works. I'm concerned that this >>> might be like comparing two Strings with the == operator; sometimes it >>> will >>> show equality and make you think it is confirming equality of value >>> between >>> the two strings but it is not; you have to use equals() to compare >>> String >>> values. But I'm not sure what the equivalent is for an enum. > > This is fully covered in the docs for enums, which you clearly have not > read. In fact, I _did_ read some Java articles on enums and they did NOT mention that the == operator was the correct one to use. Apparently, I read the wrong articles.... -- Rhino |