Carey, Just wanted to let you know I haven't forgotten this mail. Just a bit busy at the moment to look at it.
Regards, Glen ----- Original Message ----- From: "Andrew C. Oliver" <[EMAIL PROTECTED]> To: "Carey Sublette" <[EMAIL PROTECTED]> Cc: "POI Development" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, April 02, 2002 1:13 PM 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'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). > > -Andy > > > On Mon, 2002-04-01 at 19:18, Carey Sublette wrote: > > I'm not sure what the proper procedure is for submitting revised code for > > possible incorporation into Poi. > > > > Attached are source code files (HSSFUserRuntimeException.java, > > HSSFListener.java) for changes to allow HSSFListeners to abort workbook > > processing. The changes made were trivial, just the creation of new > > exception class, and the addition of throwing the exception to the listener > > interface. I cloned the HSPFRuntimeException to make the > > HSSFUserRuntimeException, only changing its name and the Javadoc comments > > (not out of laziness, but to promote consistency within Poi). > > > > I reviewed the HSSF code to look for possible pitfalls of throwing the > > exception while processing a workbook. The only possible risk I could think > > of would be a static member variable that holds on to a big object as long > > as the class was loaded (really bad practice) and of course I didn't see > > anything like this. > > > > I did testing with processing really large spreadsheets (up to 100 MB) and > > throwing exceptions during the processing. It worked fine and I confirmed > > that I got all of the memory back when System.gc() was called right after > > return from HSSFEventFactory. > > > > Carey Sublette <<HSSFUserRuntimeException.java>> <<HSSFListener.java>> > -- > 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 >
