Hi Nick, You ever seen the movie "The Magnificent Seven"? One of the wisdom to be taken from this film, which I believe maps fully esp. to developers is that we sometimes act like this man from El Paso.. http://www.imdb.com/title/tt0054047/quotes#qt0345610
As I had been the lead developer from the original ODF Toolkit at that time, where Simple API later was forked from (the Java doc package), let me take the blame for the package dependent methods like loadDocument. I did it as it seemed to be a good idea at that time. In more detail, when we were starting with load methods for the document, there had been a lot of possible exceptions that would happen in the ZIP/Network/XML Parser during loading/saving and we wanted to provide more information than returning null for the document when there had been problems during loading a document. Nowadays, after reviewing this years later, I would likely return two different types of Exceptions, one telling you that something is wrong with the document (e.g. corrupt Document Exception - opening an image, or something is wrong with the environment (network, can not find file). In those days, the problem was not differentiated in our supported software so, we did not spend the effort to differentiate. PS: What I have added later for validation purpose was an implementation of the SAX Error Handler <http://docs.oracle.com/javase/6/docs/api/org/xml/sax/ErrorHandler.html>, which was not only listening to SAX XML Parsing problems, but as well for general ODF validation problems. Even PACKAGE ZIP problems are being reported to the error handler (event listener) instead of throwing exceptions, otherwise an invalid document would not be loaded. The highest demand of a user is to be able to load its document at any costs, even if it is broken, the user wants to recover the data. So loading should be as robust as possible, validation errors are just reported as events to the error handler and could be read after loading, e.g. from the validator (Seems we have no uploaded online JavaDoc, do we?). Still as all validation this costs time and has to be requested explicitly via parameter, otherwise no error handler/validation will be applied. Does this clarify the question or where you referring to different kind of code? Your scenario was not very specific, could you provide further Information, Nick? Greetings from the Berlin, Svante On 18.10.2012 20:30, Nick Burch wrote: > Hi All > > Despite being a mentor of the project, rather shockingly I've only > just tried to use ODF Toolkit in anger... Sorry! > > I have some existing code which uses Apache POI to generate Excel > files (.xls and .xlsx), which I'm trying to convert to also generate > ODS ones too using ODF Toolkit. I'm using the Simple API to do this. > > One thing that immediately struck me though was the "throws Exception" > everywhere. In general, I'm not a big fan of needing catch(Exception > e) in my code for things like this, as I often want to be able to tell > the difference between an expected problem and something unusual. > > Is there a reason for the general Exception throws everywhere? > > Related, both Apache POI and Apache Tika, which are fairly similar > libraries, have fairly tight throws clauses, so if there is a good > reason for the difference it strikes me it's worth putting that on the > website to explain why it does something different > > Cheers > Nick
