incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svante Schubert <svante.schub...@gmail.com>
Subject Re: ODF Simple and throws Exception
Date Fri, 19 Oct 2012 14:23:27 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message