Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: About java program. Date: Sat, 6 Jul 2013 14:17:24 +0000 (UTC) Organization: A noiseless patient Spider Lines: 118 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> <51d77b0d$0$290$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sat, 6 Jul 2013 14:17:24 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="3396"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+8Xxkxm7axuCbji2LjWdyaaMMHZya7bUo=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:Q28pMg8Pb6Yqj/34SuoX8DdxSsk= Xref: csiph.com comp.lang.java.programmer:24682 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 |