Parse Exception: At line 1, column 0: no element found

I have a weird issue. I receive the following error that causes a force-close:

org.apache.harmony.xml.ExpatParser$ParseException: At line 1, column 0: no element found at org.apache.harmony.xml.ExpatParser.parseFragment(ExpatParser.java:508) at org.apache.harmony.xml.ExpatParser.parseDocument(ExpatParser.java:467) at org.apache.harmony.xml.Exp开发者_StackOverflow中文版atReader.parse(ExpatReader.java:329) at org.apache.harmony.xml.ExpatReader.parse(ExpatReader.java:286)

After clicking the Force Close button, the Activity is recreated and the parsing completes without a hitch. I'm using the following code snippet inside doInBackground of an AsyncTask:

URL serverAddress = new URL(url[0]);

HttpURLConnection connection = (HttpURLConnection) serverAddress.openConnection();
connection.setRequestMethod("GET");
connection.setDoOutput(true);
connection.setReadTimeout(10000);
connection.connect();

InputStream stream = connection.getInputStream();

SAXParserFactory spf = SAXParserFactory.newInstance();
SAXParser sp = spf.newSAXParser();

XMLReader xr = sp.getXMLReader();

xr.parse(new InputSource(stream));  // The line that throws the exception

Why would the Activity force-close and then run without any problems immediately after? Would a BufferedInputStream be any different? I'm baffled. :(

Thanks for your time everyone.

Update: It turns out HttpURLConnection.getResponseCode() returns -1 every so often, so the InputStream probably isn't being correctly set.

---

HTTPURLConnection connection = (HttpURLConnection) serverAddress.openConnection();
connection.setRequestMethod("GET");
connection.setDoOutput(true);

Those lines are a bit odd. Is it HTTPURLConnection or HttpURLConnection? The default request method is already GET. The setDoOutput(true) will however force it to POST.

I'd replace all of those lines by

URLConnection connection = serverAddress.openConnection();

and retry. It might happen that it returned an error because you forced POST and didn't write anything to the output (the request body). The connection.connect() is by the way already implicitly called by connection.getInputStream(), so that line is superfluous as well.

Update: does the following for testing purposes work?

BufferedReader reader = new BufferedReader(new InputStreamReader(stream, "UTF-8"));
for (String line; (line = reader.readLine()) != null;) {
    System.out.println(line);
}
reader.close();

---

I dont' know if you fixed this, but I had the same problem. It was weird, it would work fine in the emulator, but then on the phone, it was always giving me the xr.parse() error. Even when I printed the InputStream it would give me legitimate output of the xml document. It seemed the problem was in the creating of the InputSource object

Here's how I fixed it: instead of using InputStream to create your InputSource I just created input source from the url string directly.

InputSource a =  new InputSource(url_string);   

where url_string is just a string with your url. Don't ask me why it works...I dont really like it, as there's no way to check for timeouts and things like that it seems. But it works, let me know how it goes!

---

Per InputStream javadoc the method will block until the data is available or the EOF is encountered. So, the other side of Socket needs to close it - then the inStream.read() call will return.

If you use BufferedReader , you can read in a line-by-line manner. The readLine() method will return as soon as a line from HTTP response is read.

---

On a related design note, loading up contents of a URL should never Force Close an activity - I recommend putting all this into an AsyncTask implementation and report or retry after you are back on the GUI thread.

---

Even I faced the same issue. I was first using the InputStream in Scanner to print the content of it. And then trying to pass it in XML parser.

The problem was that I was not closing the Scanner object. And using the Inputstream in parser.

After closing the scanner object, I was able to tackle this issue.

---

I ran into the same problem and could make no sense of it because I was parsing directly from the InputSource. When I modified the code to pull the result into a string before the xml parse, I found out the problem was simply a mispelled web service method name and that the error message reported by that service was the killer.