Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Nigel Wade Newsgroups: comp.lang.java.help Subject: Re: When to throw exceptions and when to use System.err? Date: Thu, 31 Mar 2011 15:58:31 +0100 Lines: 75 Message-ID: <8vjj4oFn46U1@mid.individual.net> References: <87bp0w8gd4.fsf@merciadriluca-station.MERCIADRILUCA> <8vbe38Fcc2U1@mid.individual.net> <87wrjjw513.fsf@merciadriluca-station.MERCIADRILUCA> <2ojkp.63$g56.35@newsfe04.iad> <5ctkp.30$ua4.10@newsfe10.iad> <845bd06b-b2c4-4c57-896c-a8d2347c7c75@m7g2000vbq.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net lEqt87jJ+EH0wA3RnqB83gXf8CBUDXJlmmFHNoaybx88Wz2plQ Cancel-Lock: sha1:CwpdusrsH3IGYnEhCn9wQLFOeb4= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.help:465 On 31/03/11 14:55, Eric wrote: > On Mar 30, 11:49 pm, Lew wrote: >> Eric wrote: >>> There is a bad user input exception but the point is that it's a >>> program problem by the time it becomes an exception. >> >> I agree with the point so I won't quibble with the phrasing. >> >>> If your program accepts the value of 12 from user input where it >>> expects a value no greater than 10, it's already gotten past the user >>> input program with incorrect or incomplete validation. >> >> Which is not an input problem. >> >>> I would think printing (err.println) should only be for debugging, not >>> necessary for live programs. >> >> That would be entirely up to the specifications for the "live" program. >> >> System.err.println() is not a good choice for debugging. It's not a terrible >> choice for probing development alternatives, but it's still infelicitous. So >> only use it where the application requirements call for it. >> >> As for what's good for debugging, when debugging is called for, nothing beats >> a debugger. When it is not called for, you leverage the tools available to >> the production environment, namely logs. Bear in mind when you write logging >> code that its purpose is to support operations, and we developers ride on >> those coattails. Logging should not be designed selfishly for a programmer's >> convenience. >> >>> Your last point is an interesting question. Don't ignore exceptions? >>> What does this mean? >> >> That wasn't /my/ point. That was a chapter ("Item") title from /Effective >> Java/ by Joshua Bloch, 2nd ed. Buy it. Study it. >> >> Ignoring exceptions means exactly what the words denote: not paying attention >> to them. >> >> There are two kinds of exceptions (by which I mean improper subtypes of >> 'Exception'): runtime, or unchecked exceptions, and checked exceptions. >> >> One way to ignore runtime exceptions is to completely ignore them and allow >> them free rein to crash your app: >> >> public void foo( String sometxt ) >> { >> System.out.println( "Input length "+ sometxt.length() >> +" value\n\""+ sometxt +'"'; >> } >> >> Oops. This just lets the runtime exception percolate up out of the method to >> damage the caller. > > What runtime exception? There's a potential NPE which will be thrown if the caller passes in a null String. > You didn't catch or throw any exceptions > there. No, none were caught, but an NPE may be thrown. > Eclipse doesn't have any warnings or errors on that block, > other than the syntax error for the missing ). > It won't have. NPE is a RuntimeException so doesn't need to be declared, or caught. It will, however, crash your program if it occurs and you don't catch it. -- Nigel Wade