Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: redesign exception Date: Wed, 29 Oct 2014 22:05:53 +0000 (UTC) Organization: A noiseless patient Spider Lines: 37 Message-ID: References: <1d6fc97wumvl6$.316nwmuziazw.dlg@40tude.net> <6e29c258-9842-4c60-9d99-9929a92d7a96@googlegroups.com> <6429a7c1-3430-4897-aa9b-a9836d9d8a40@googlegroups.com> <5sednVQ7leDCSdDJnZ2dnUVZ8lWdnZ2d@giganews.com> <6fa2df26-9917-49b8-8366-087afdcc06f8@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 29 Oct 2014 22:05:53 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="32445"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19XlULTXQOp72SN/dD/Gy0PI1Ne+1Fd9Ds=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:WJUvTJ4YFj5/1j7r9cx2j/699oI= Xref: csiph.com comp.lang.java.programmer:30239 On Wed, 29 Oct 2014 18:59:47 +0100, Robert Klemme wrote: > On 29.10.2014 18:29, Martin Gregorie wrote: > >> I believe a good case can be made that invalid data isn't really an >> Exception because having both good and bad data input is part of normal >> processing and therefore something like a boolean VALID/INVALID return >> from the checking method is alll that's needed. Throwing exceptions >> should be reserved for processing errors, e.g. a public holiday check >> on an in-range future date discovering that the valid public holiday >> list doesn't cover all permitted future dates, or finding that the >> input represents a security violation serious enough to require >> attention from somebody other than the user who input it. > > We could discuss quite a bit about this... If the interfacing code does > not ensure valid input is passed on than it is totally appropriate for > lower layers of code to flag this as a processing error (usually via a > RuntimeException like InvalidArgumentException or NPE). A checking > method with a boolean (or more sophisticated) return value can only ever > be a useful helper but the code receiving data still needs to throw if > the contract is violated. There is really no other way. > Sure. I was only talking about parts of a program where invalid data should be expected as a normal part of the data stream, for instance around input validation methods that sit behind an input screen, which are going to recycle bad input by telling the user what's wrong with his input and inviting corrected data to be supplied. You do the same with incoming mail. An invalid recipient address isn't really exceptional: you get them all the time and spit them back whence they came with a 5xx SMTP error, meanwhile passing clean input on to the archiving and delivery systems. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |