Re: About java program.
On Sat, 06 Jul 2013 13:01:56 +0200, Robert Klemme wrote:
On 06.07.2013 04:03, Arne Vajh??j wrote:
On 7/5/2013 5:15 PM, Robert Klemme wrote:
On 05.07.2013 10:13, lipska the kat wrote:
private boolean askYesNoquestion (String str) throws
BadArgumentException{
boolean result = false;
if(null == str){
logger.log("Argument is null");
throw new BadArgumentException("Argument is null");
}
else{
if(str.equals("yes")){
result = true;
}
else if(!str.equals("no")){
logger.log("Incorrect Argument, argument is " + str);
throw new BadArgumentException("argument is " + str);
}
}
return result;
}
This is *one* way of doing it
Overkill ... no, defensive yes.
This example demonstrates what I will call bad practice: the exception
is thrown so the calling code can decide how to handle the error. It
may actually be that the caller can perfectly deal with that situation
and proceed normally. Method askYesNoquestion() cannot know this.
But because the method does the logging itself you'll end up seeing
messages in a log file for things which are not noteworthy. I say,
either log and deal with the error locally OR throw an exception
containing a meaningful message - but not both. That is misleading.
I do not agree with the last point.
If we look at the matrix:
caller logs caller do not log
log insignificant extra log entry fine
I do not agree to the "insignificant".
not log fine big problem troubleshooting
then it seems obvious to me to log anyway. Worst case by logging is not
nearly as bad as worst case not logging.
Maybe I haven't made myself clear enough: it is the task of the writer
of the calling code to decide whether the exception is a problem or not.
Basically the author has two things to do:
1) return valid answers (in this case true for 'yes' and false for 'no'
2) decide what to do with errors, i.e. inputs that can't be easily
and unambiguously resolved into true or false.
In dealing with the errors I think its worthwhile distinguishing between
things that happen routinely during a run (in this case and input that
isn't "yes" or "no") that the calling code is expected to deal with as
part of its normal operation and less common stuff (e.g being handed a
null pointer rather than a String instance. This distinction makes
writing the caller much easier.
So, in this case, I'd probably reserve use of an exception for dealing
with a null and add a third return code for the wrong string value,
because this lets the caller write something like:
Prompter p = new Prompter("Is it teatime yet");
char answer = Prompter.BAD_REPLY;
try
{
while (answer == Prompter.BAD_REPLY)
answer = p.getResponse();
}
catch (PrompterException e)
{
logger.abandon("Error: " + e.getMessage());
}
if (answer == Prompter.AFFIRMATIVE)
......;
else
......;
I started to use this type of error processing after my first brush with
PL/1, where the i/o system throws exceptions for everything from real
exceptions such as file not found or disk errors, when you want to stop
the run, and expected events such as end of file or key not found, which
need to be handled within the normal logic flow. I found that the need to
go through an exception handler just to deal with normal events such as
end of file made the logic harder to follow because in PL/1 there's
nothing like the try..catch block: about all you can do is like this:
dcl EOF char(1) init('N');
on endfile(file1) EOF = 'Y';
do while(EOF = 'N')
begin
read file(file1) into(inputrec);
.....
end
Consequently, I tend to write Java such that expected events in a method
call will return a value indicating success or failure and the method
will only throw an Exception when the best thing the program can do is
quit. The need to use a getter to retrieve the expected result seems like
a worthwhile price to pay the cleaner logic flow in the calling code.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |