Yes, having more specific exceptions is usually helpful, as it allows
the code to handle various cases differently.
Otherwise, would there ever be a need for any type of exception except
the base Exception class?
In this case, having a PDFParseException, or at least a ParseException
provided by PDFBox instead of just an IOException would tell us that
there is no problem with the file itself or the input and output of the
file into the parser, but that something went wrong with the parsing.
When it becomes a TikaException instead of an IOException is when it
becomes the most useful, because that then allows my software to
distinguish between an event caused by parsing versus some general
problem with the file. Imagine if it wasn't an IOException and was just
an Exception. Then my programming would have to be even more generic and
not be able to handle the exception as specifically.
On 7/11/2014 2:08 AM, James Green wrote:
This raises an interesting question, and one that applies to software in
general. I actually think PDFBox has it right - something more specific
might sound correct but to whom is it is useful? Exceptions in my
experience tend to bubble straight to the user (perhaps logged to file, and
an "oops" given to the user). The user in this case needs to be told
there's something wrong with the file, and the error itself says what.
Does PDFParseException give your software some new behaviour?
