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 >
