Which one is better?

[howa]

Aim: To add a member into the system

Method 1:

If ( system.validation ( member ) ) {
system.addMember( member );
}

Method 2:

if (! system.addMember( member ) ) {
System.out.println("Adding failed");
}

where the validation logic is in the addMember method.

Which one you prefer?

 

[Piotr Kobzda]

Aim: To add a member into the system

Method 1:

If ( system.validation ( member ) ) {
system.addMember( member );
}

Method 2:

if (! system.addMember( member ) ) {
System.out.println("Adding failed");
}

where the validation logic is in the addMember method.

Which one you prefer?

2 or:

Method 3:

system.addMember( member );

where addMember() throws IllegalArgumentException (or more specific
exception).


piotr

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

2 or:

Method 3:

system.addMember( member );

where addMember() throws IllegalArgumentException (or more specific
exception).

If adding failing is an exceptional occurrence then #3 else #2.

Arne

 

[Patricia Shanahan]

If adding failing is an exceptional occurrence then #3 else #2.

Agree. Both are better than #1 because #1 incorporates two unnecessary
assumptions:

1. That the result of system.validation does not change between the two
calls. It is possible that the critical portion of addMember is
synchronized.

2. That system.validation failure is the *only* way addMember can fail.
Even if that is the case now, #1 would not be robust under future
development in addMember.

Of course, #2 is better than #3 if addMember cannot be changed.

Patricia

 

[Mark Space]

Of course, #2 is better than #3 if addMember cannot be changed.

Do you think it would be better to have addMember() throw a Runtime
exception instead if it cannot be changed?

 

[Patricia Shanahan]

Do you think it would be better to have addMember() throw a Runtime
exception instead if it cannot be changed?

If it cannot be changed to throw an appropriate exception, with the
implication that any existing code will be changed appropriately, I
would stick with the existing interface and use #2.

Suppose there is an existing user of #2, and addMember is changed to
throw an appropriate checked exception. The #2 code will not compile
until it is changed to deal with the new exception. If addMember were
changed to throw a RuntimeException, the existing #2 code would fail
mysteriously when addMember fails.

Patricia

 

[Roedy Green]

Method 1:

If ( system.validation ( member ) ) {
system.addMember( member );
}

Method 2:

if (! system.addMember( member ) ) {
System.out.println("Adding failed");
}

There is a third more Javaesque method.

Method 3:
try {
...
system.addMember( member );
....
catch ( InvalidMemberException e )
{
// Note that one catch often services
// several possible places the exception could be triggered.
System.out.println("Cannot add invalid member.");
System.out.println( e.getMessage() );
}

The two techniques you showed are more common in C code.
They might be used in Java if the probability were of failure were
high, especially method 2.

Method 1 in mainly used in methods like "hasNext".