Prev: Open source licensing being questioned by anti-copyrighttypes
Next: Suggession for your website
From: Rhino on 28 May 2010 21:07

> 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. But now that I think about it, this would also work well:

public static final boolean METHOD_WORKED = true;
public static final boolean METHOD_FOUND_ERROR = false;

PadResult padResult = new PadResult(METHOD_WORKED, paddedString);

PadResult padResult = new PadResult(METHOD_FOUND_ERROR, errorMsg);

if (padResult.getStatus()) {
//got padded string
}
else {
// found error
}

[Not tested or compiled yet!!]

Of course, the down side to this approach is that I may have to make a
number of these little holder classes, depending on what each one's normal
return value is. I have methods that return Strings but others that return
ints or Sets or Maps or timestamps or etc. etc. and I'll tend to need of
these little classes for each type of return that a method can give.

They're small, simple classes but there will eventually be a number of
them.....

--
Rhino


From: Arne Vajhøj on 28 May 2010 21:34
On 28-05-2010 20:43, Rhino wrote:
> "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message
> news:4c005ae9$0$281$14726298(a)news.sunsite.dk...
>> On 28-05-2010 19:02, Rhino wrote:
>>> It's the if statement that concerns me here. This code works fine (I can
>>> test for CompletionStatus.NO_ERROR by simply changlng the right side of
>>> the
>>> if) but it doesn't look right. It reminds me of mistakes I made when I
>>> was
>>> new to Java comparing Strings to each other via the == operator to see if
>>> they had the same VALUE but discovering that == doesn't determine
>>> equality
>>> of value.
>>
>>> Is there a better way to do this if statement? If so, what is it?
>>
>> I would compare with CompletionStatus.NO_ERROR, because it is
>> a lot more likely that you will have more than one error status
>> than more than one no error status.
>>
> 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.

== on enums are fine.

Object identity is exactly what is needed.

Arne
From: Jeff Higgins on 28 May 2010 23:05
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))
}

From: Lew on 28 May 2010 23:26
On 05/28/2010 07:02 PM, Rhino wrote:
> I'm trying something Eric Sosman suggested on another thread but I have
> doubts about one of the idioms so I thought I'd check here and see if there
> was a better way.
>
> A method name pad() returns a special class called PadResult. PadResult is
> defined as follows:
>
> import CompletionStatus;

You don't import from the default package.

In fact, you shouldn't have any code in the default package in the first place!

--
Lew
From: Lew on 28 May 2010 23:27
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.

--
Lew
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Open source licensing being questioned by anti-copyrighttypes
Next: Suggession for your website