aspose file tools*
The moose likes Java in General and the fly likes Most accurate built-in exception for XML parsing error Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Most accurate built-in exception for XML parsing error" Watch "Most accurate built-in exception for XML parsing error" New topic
Author

Most accurate built-in exception for XML parsing error

Jayesh Bhoot
Greenhorn

Joined: Jan 25, 2013
Posts: 4
In my new project, I am trying to minimize usage of custom exceptions.

Currently, I am stuck at choosing the most appropriate exception in a method that parses JSON/XML. Class in question is called ResponseParser, the ResponseParser.parseBook() method of which takes in a response (currently XML, but might convert into JSON later), and parses it to spit out a Book object.

To parse the XML, I am using DocumentBuilder coupled with XPath and its associates. Their methods make me catch/handle a lot of exceptions, like IOException, ParserConfigurationException, SAXException, etc.

Am I correct to believe that I should rethrow these exceptions after wrapping them in a common, less confusing exception, so that another entity using this parseBook() method doesn't have to deal with all the above mentioned exceptions? If not, then what is the better alternative?

In case I am correct to assume so, what is the best built-in exception to throw in this case? I thought of using java.text.ParseException, but it makes me set an offset field, which is totally unnecessary in my case. I couldn't find any other appropriate exception to use. Also, ParseException being a checked exception, also gives another error Unhandled exceptions: java.lang.Throwable.

Here is my current code:
Stuart A. Burkett
Ranch Hand

Joined: May 30, 2012
Posts: 679
Mister Bhoot wrote:Also, ParseException being a checked exception, also gives another error Unhandled exceptions: java.lang.Throwable.

That error is not due to ParseException being a checked exception. You are not throwing a ParseException. You are throwing what is returned by the initCause method which is a Throwable.
If you want the ParseException to include a cause, you can only do that in three separate statements
Create the exception
Set the cause
Throw the exception.

Edit: actually you could do it all in one statement by including a cast to ParseException.
Jayesh Bhoot
Greenhorn

Joined: Jan 25, 2013
Posts: 4
Stuart A. Burkett wrote:
Mister Bhoot wrote:Also, ParseException being a checked exception, also gives another error Unhandled exceptions: java.lang.Throwable.

That error is not due to ParseException being a checked exception. You are not throwing a ParseException. You are throwing what is returned by the initCause method which is a Throwable.
If you want the ParseException to include a cause, you can only do that in three separate statements
Create the exception
Set the cause
Throw the exception.

Edit: actually you could do it all in one statement by including a cast to ParseException.


Alright. You got me there.
And do you have any suggestions as to what exception should I be throwing in the first place? Or should I just create a custom exception and be done with it?
And is my approach correct?
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12682
    
    5
The exception you want to have first in the chain is SAXParseException - the reason being that you can usually extract line number and column number from a parse exception.

With line and column you can examine the input document - lots of possible causes so examining the actual text is essential. Use a programmer's editor so you can detect illegal characters.

Bill

Java Resources at www.wbrogden.com
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 13884
    
  10

Mister Bhoot wrote:Am I correct to believe that I should rethrow these exceptions after wrapping them in a common, less confusing exception, so that another entity using this parseBook() method doesn't have to deal with all the above mentioned exceptions? If not, then what is the better alternative?

It's not really a question of what's "correct" - it's more about what makes your parseBook() method easy to use. It certainly makes it easier if your method throws just one type of exception instead of a whole bunch of different kinds of exceptions.

A philosophical problem with just adding all exceptions that might happen in the method to the throws-clause of the parseBook() method is that it exposes implementation details of the method to the user. A class with a well-designed API shouldn't expose implementation details through its API.

So, in my opinion, it's a good idea to wrap all those exceptions in another exception. Whether you reuse the existing java.text.ParseException or you make your own custom exception is also not a question that has a right or wrong answer.

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Jayesh Bhoot
Greenhorn

Joined: Jan 25, 2013
Posts: 4
William Brogden wrote:The exception you want to have first in the chain is SAXParseException - the reason being that you can usually extract line number and column number from a parse exception.

With line and column you can examine the input document - lots of possible causes so examining the actual text is essential. Use a programmer's editor so you can detect illegal characters.

Bill


I feel that the SAXParseException would leak the implementation detail out of the ResponseParser class. Moreover, its a checked exception that I want to avoid.
I am also going to avoid ParseException as it too enforces me to use throws ParseException in constructor, enforcing the user of the class to wrap the constructor in a try-catch block. Too yucky for my taste. Even if the user uses the try-catch block, there is nothing much it can do in the catch block anyway. So, I would better throw an unchecked exception; code will look cleaner at least.
Jayesh Bhoot
Greenhorn

Joined: Jan 25, 2013
Posts: 4
Jesper de Jong wrote:
Mister Bhoot wrote:Am I correct to believe that I should rethrow these exceptions after wrapping them in a common, less confusing exception, so that another entity using this parseBook() method doesn't have to deal with all the above mentioned exceptions? If not, then what is the better alternative?

It's not really a question of what's "correct" - it's more about what makes your parseBook() method easy to use. It certainly makes it easier if your method throws just one type of exception instead of a whole bunch of different kinds of exceptions.

A philosophical problem with just adding all exceptions that might happen in the method to the throws-clause of the parseBook() method is that it exposes implementation details of the method to the user. A class with a well-designed API shouldn't expose implementation details through its API.

So, in my opinion, it's a good idea to wrap all those exceptions in another exception. Whether you reuse the existing java.text.ParseException or you make your own custom exception is also not a question that has a right or wrong answer.


You almost mirrored my thoughts. :-)
It feels good to be right about something that you are new at!

I guess I will move on with a custom exception in this case. The built-in java.text.ParseException is a checked exception, which I want to avoid. There is nothing a user entity could do in the catch block anyway, in case I use a checked exception.

Thanks for the input.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Most accurate built-in exception for XML parsing error
 
Similar Threads
'reading' an xml document - what am i doing wrong?
DOM (xml) question
Parsing XML elements
DocumentBuilder.parse not working for String input
javax xml parsers FactoryConfigurationError