Upon further thought, we do need a checked exception for this. In a system that processes lots of spreadsheets sooner or later you're going to get a bad one...
-Andy On Mon, 2002-04-08 at 15:17, Andrew C. Oliver wrote: > Alright, just post to dev not pier and to me. (pier probably isn't > interested and I only need one :-) > > Exception errors are one thing. "Hi I don't feel like processing any > more" is another. I think invalid data should be a runtime exception: > "RecordFormatException". I think application-based exit situations > should be result-code based. > > Thoughts? > > -Andy > > Carey Sublette wrote: > > >Hi Andrew: > > > >>From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] > >>Sent: Monday, April 01, 2002 7:13 PM > >>To: Carey Sublette > >>Cc: POI Development; [EMAIL PROTECTED] > >>Subject: Re: Interface Change to HSSF (AND mail list problems) > >> > >> > >>Hi Carey, > >> > >>Can you try subscribing the the dev list once more? Do you receive > >>mails and just cant send them or are left out all together. I'm > >>confident with Pier's help we can find the answer. > >> > > > >I am getting the poi-dev messages sent to me, and this message will test > >whether I can post to the poi-dev list. > > > >I am not getting the poi-user messages, nor have repeated attempts to post > >to it been successful. I resubscribed to poi-user again today (making it > >three subscription attempts). > > > >>I'm leaving this up to Glen. I personally don't like this patch and > >>would prefer the listener to return status (basically on whether it > >>would like to cause an exit condition). I'm not sure why I don't like > >>it exactly just it feels wrong. > >> > >>In the event of a catastrophic record format condition HSSF already > >>could throw a record format exception. > >> > >>Furthermore, its possible someone may simply want to exit not because of > >>some error, but because they grabbed the data they wanted. I'd prefer a > >>solution that handles both cases. (Via an error or status condition > >>perhaps just a boolean return value). > >> > > > >Sure, many type of termination conditions are possible (my own application > >uses non-error termination in addition to errors). > > > >The solution should definitely provide for the user code to return status > >information that the would be passed back when the call to HSSF returned. > >This should be an object type that the user can extend to add the specific > >type of status information needed - for example a numeric status code, in > >addition to or instead of a message string. > > > >The normal pattern in Java for aborting processing and returning status > >information is via some type of Throwable - which need not represent an > >actual error condition. If the HSSF code were modified to be "exception > >aware" then it need not (in fact, should not) be a RuntimeException. > > > >Carey > > > > > -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh
