Re: About java program.
On 06.07.2013 04:03, Arne Vajh=F8j 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. Bu=
t
because the method does the logging itself you'll end up seeing messag=
es
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. =
This decision cannot be done by the author of this method. Presumably =
this is a low level method which is invoked from many different places
and so some may be able to handle the exception while some may not.
Since a RuntimeException (NPE is one) will be likely caught somewhere
high up the call chain and logged there (usually with the stack trace)
debugging should not be too difficult. If on the other hand you need to =
wade through tons of log messages which do not signal an error then
debugging is also harmed. Not to mention the additional IO overhead for =
all the superfluous log messages.
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/