Re: About java program.
On 06.07.2013 10:16, lipska the kat wrote:
On 05/07/13 22:15, Robert Klemme wrote:
On 05.07.2013 10:13, lipska the kat wrote:
On 05/07/13 04:11, Arne Vajh=F8j wrote:
The above has nothing to do with defensive coding. It does
not protect against anything that the simple:
For goodness sake *read the post*
I said 'lack of error handling notwithstanding'
Do you understand what that means?
Do you want an example of defensive coding?
READ THIS FIRST
This is an *example* ... got that, good.
Funny thing is that people will only see in an example what is present=
ed
in the example. So if there is an example which leaves place for
specific error handling and that error handling is not included people=
won't see it. They just see a method with unnecessary complexity.
Maybe you'll say it's not easy to pick a good example. But examples a=
re
there for a reason: they are used as tools to communicate something. =
If
they fail to do that they should be improved or left out.
and no, I haven't compiled it and no, I wouldn't normally hard code
messages in this way (jeez)
Now then
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 situat=
ion
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.
Frankly I think you are missing the whole point of defensive programmin=
g.
You yourself said
"It may actually be that the caller can perfectly deal with that
situation..."
The important word here is *may* ... what happens if the caller decides=
to ignore the exception, or maybe handle it without recording the
reason. What are you left with ...
Well, you can forget the logging on *any* level of the application.
There is no really a difference between asking the author of this method =
to do proper error handling or asking the author of some other code to
do it.
The example is trivial I agree but the concept is sound.
If you do that kind of logging in all sorts of methods you'll end up
with extreme volumes of logfiles that make it hard to detect real bugs
and cost significant IO.
... and who says these things are not *noteworthy*. If you are
programming defensively then *everything* is noteworthy.
For me "defensive programming" in this example means to check arguments
and throw NPE or IllegalArgumentException if the data passed into the
method violates the specified (e.g. in JavaDoc) contract. Nothing more. =
Errors will show up. If the caller does not handle exceptions
properly then the exception will show up somewhere up the call stack
where it's logged or presented to the user. Easy to find bugs then.
IMHO it is bad practice *not* to log the error at the point of origin.
The point is: you do not know whether it _is_ an error inside this
method. You know arguments violate the contract, but you do not know
whether that poses a problem for the program. Hence: throw an exception =
and be done.
There's an old adage in this business "You can never have too much data=
"
This is especially true when programing defensively.
I disagree.
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/