Path: csiph.com!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: About java program. Date: Sat, 06 Jul 2013 13:14:00 +0200 Lines: 134 Message-ID: References: <324f929f-772e-4004-81e1-6b454cdae794@googlegroups.com> <19wnriq53qxel.u9rt8wy6z52g.dlg@40tude.net> <1lvu4yv8sxe73$.n4o05ixuag9y.dlg@40tude.net> <85GdncWZdo04-lzMnZ2dnUVZ8mydnZ2d@bt.com> <51d6396c$0$295$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net Cy3opWW0SUPabcYsrb0cbQw0Y+9dpOoAoXaV2cOw1xRDvfpBI= Cancel-Lock: sha1:hwq4uYi8We3RpbDf3HafqB4CNb0= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: X-Antivirus: avast! (VPS 130705-1, 05.07.2013), Outbound message X-Antivirus-Status: Clean Xref: csiph.com comp.lang.java.programmer:24677 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 =3D false; >>> >>> if(null =3D=3D str){ >>> logger.log("Argument is null"); >>> throw new BadArgumentException("Argument is null"); >>> } >>> else{ >>> if(str.equals("yes")){ >>> result =3D 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.=20 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=20 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=20 with extreme volumes of logfiles that make it hard to detect real bugs=20 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=20 and throw NPE or IllegalArgumentException if the data passed into the=20 method violates the specified (e.g. in JavaDoc) contract. Nothing more. = Errors will show up. If the caller does not handle exceptions=20 properly then the exception will show up somewhere up the call stack=20 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=20 method. You know arguments violate the contract, but you do not know=20 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 --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/