2

I'm trying to track down the source of an EOFException in some client/server code, but many of the classes used only have methods which say that they throw an IOException, not specifically an EOFException. Normally I'd just look at the stack trace but I don't have it and can't reproduce it. So, it would be helpful to have a list of every class which has methods which throw EOFException specifically, but I don't know how to find out this information.

Is there a source of information on every (standard) Java class (in SE 7, in my case) which has methods which throw EOFException? I have tried reading the Javadocs on EOFException to no avail.

(I have found, at least, that DataInput does mentionEOFException. But are there any more?)

Afterword: Since it seems the only way to find out is to inspect the source code, here is the result of me searching for "EOFException" in the extracted source code (1.7.0_45).

2rs2ts
  • 10,662
  • 10
  • 51
  • 95
  • 1
    Download the source for the core java libraries, create a project for them, do a search in the project using your IDE of choice. – Tim B Jan 30 '14 at 13:53
  • Basically any stream class could throw this. – Sotirios Delimanolis Jan 30 '14 at 13:54
  • @TimB Is this the only way? – 2rs2ts Jan 30 '14 at 13:54
  • Take a look [here](http://docs.oracle.com/javase/7/docs/api/) – Ashot Karakhanyan Jan 30 '14 at 13:55
  • An EOFException means that a file or stream ended prematurely - knowing where that came from exactly in the libraries is much less important than knowing what data was read (especially since you could then replicate the issue). – Njol Jan 30 '14 at 13:55
  • @Njol It's hard for me to reproduce the issue in this case without knowing which part of the code is actually reading this data. In fact, it's hard for me to reproduce the issue at all, since in my particular circumstances I don't know how to run some of the system under question. Long story short, I am trying to reproduce this with a unit test, not functionally. – 2rs2ts Jan 30 '14 at 14:00
  • This question should really be "all Java standard library classes" instead of just "all clases". As soon as someone gives you a complete list of all classes, I could just write another one. – Rainbolt Jan 30 '14 at 14:00
  • @Ingo Okay, you know what I mean... – 2rs2ts Jan 30 '14 at 14:02
  • @John You're right, I will edit. – 2rs2ts Jan 30 '14 at 14:02
  • 1
    Note: javadoc, http://docs.oracle.com/javase/7/docs/api/java/io/class-use/EOFException.html does not help here. – Joop Eggen Jan 30 '14 at 14:28

2 Answers2

3

EDIT: Added results for 7.51, for all source code in the JDK, at the bottom.

In Java 6.17, here are all classes that explicitly throw java.io.EOFException. Specifically, it is the number of times new\s+EOFException was found in each source-code file.

java.io.DataInputStream.java: 8
java.io.ObjectInputStream.java: 6
java.io.RandomAccessFile.java: 8
java.util.zip.GZIPInputStream.java: 2
java.util.zip.InflaterInputStream.java: 1
java.util.zip.ZipFile.java: 1
java.util.zip.ZipInputStream.java: 1

Here is another bit of information: All source-code files containing catch\s*\(\s*EOFException:

java.io.ObjectInputStream.java: 1
java.util.zip.ZipInputStream.java: 1

Note that there are no standard java.* Exception classes that extend EOFException (there are no occurances of

extends\s+([a-z]+\.)*EOFException

anywhere in the java.* source-code).

This is a limited but valuable starting point. As mentioned by others, there may be situations that this misses--when all you have is the source-code to work from, it will be time-consuming to find them. Hopefully this information will set you down the right path.


Here are the results for Java 7.51, for all source-code provided with the JDK:

extends\s+([a-z]+\.)*EOFException

none

catch\s*\(\s*EOFException

com.sun.imageio.plugins.gif.GIFImageReader: 1
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl: 1
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl: 4
com.sun.org.apache.xerces.internal.impl.XMLVersionDetector: 1
com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDLoader: 2
java.io.ObjectInputStream: 1
java.util.zip.ZipInputStream: 1

new\s+EOFException

com.sun.corba.se.impl.io.IIOPInputStream: 1
com.sun.imageio.plugins.png.PNGImageReader: 1
com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl: 1
com.sun.org.apache.xerces.internal.impl.XMLEntityManager: 1
com.sun.org.apache.xerces.internal.impl.XMLEntityScanner: 1
java.io.DataInputStream: 8
java.io.ObjectInputStream: 6
java.io.RandomAccessFile: 8
java.util.zip.GZIPInputStream: 2
java.util.zip.InflaterInputStream: 1
java.util.zip.ZipFile: 1
java.util.zip.ZipInputStream: 1
javax.imageio.stream.ImageInputStreamImpl: 8
aliteralmind
  • 19,847
  • 17
  • 77
  • 108
  • (Why are you still using Java 6? Why are you using an old version of Java 6? :-) ) – Stephen C Jan 30 '14 at 14:06
  • 1
    Good answer, no upvote though as you don't say how you got the information. – Tim B Jan 30 '14 at 14:06
  • This misses a number of methods in other classes, such as in java.util.jar.JarInputStream – Ingo Jan 30 '14 at 14:14
  • In 6.17, there are no occurances of `EOFException` in `java.util.jar.*`. – aliteralmind Jan 30 '14 at 14:18
  • When I searched the SE 7 source code using that name regex I also found `javax.imageio.stream.ImageInputStreamImpl` (though it is abstract), as well as `com.sun.corba.se.impl.io.IIOPInputStream`, `com.sun.imageio.plugins.png.PNGImageReader`, `com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl`, `com.sun.org.apache.xerces.internal.impl.XMLEntityManager`, and `com.sun.org.apache.xerces.internal.impl.XMLEntityScanner`. The others in your list were also present. – 2rs2ts Jan 30 '14 at 14:21
  • @aliteralmind But this doesn't mean that you can read from a JarInputStream without having to be prepared for EOFException. – Ingo Jan 30 '14 at 14:22
  • Of course. This information is limited. It's only searching for regexes in the source code. It's a *starting point*, not a perfect reflective analysis. – aliteralmind Jan 30 '14 at 14:23
  • @2rs2ts Yes, I only searched `java.*`, not `javax.*` or `com.sun.*`. – aliteralmind Jan 30 '14 at 14:27
  • 1
    @aliteralmind Of course. I thought I'd be thorough for anyone reading this later. Those packages don't apply in my case anyway. – 2rs2ts Jan 30 '14 at 14:28
  • FWIW I should also add that [`ImageInputStreamImpl`](http://docs.oracle.com/javase/7/docs/api/javax/imageio/stream/ImageOutputStreamImpl.html) has a few subclasses. I am not going to bother figuring out whether they override the methods which throw `EOFException` in `ImageOutputStreamImpl` and then do not throw `EOFException` in those methods. – 2rs2ts Jan 30 '14 at 14:31
1

You can find that out only under the assumption that the code creates and immediately throws an EOFException. But the follwoing could also throw an EOFException:

class Foo {
    ...
    public void iAmHarmless(Exception x) { if (x != null) throw x; }
    ...
 }

Or how about the follwoing, to defeat aliteralminds method:

 class XYException extends EOFException { ... }
 class Foo {
     public void surprise() { throw new XYException().super(); }
 }

Joking aside - methods from many classes may throw EOFException simply because of inheritance. A grep for "EOFException" gives only the very base classes. But you must consider all subclasses thereof. Example: java.util.jar.JarInputStream

Ingo
  • 36,037
  • 5
  • 53
  • 100
  • 1
    In this case, the Javadocs do not mention a subclass of `EOFException`. Do you think the implementation of the Java standard libraries is really going to do something like that? – 2rs2ts Jan 30 '14 at 14:12
  • It is but 2 possible ways to conceal throwing of EOFExceptions I immediatly saw. Another one is inheritance. When you look at the short list in aliteralminds answer, you'll notice. – Ingo Jan 30 '14 at 14:16
  • @2rs2ts explained the inheritance problem. – Ingo Jan 30 '14 at 14:21
  • Of course. If I have to compile this list myself by examining the source code, then it's implicit that if a superclass has a method which throws `EOFException`, then any subclass which does not override the method(s) in question, or does so but also throws an `EOFException` in its own implementation, will also be part of the list. – 2rs2ts Jan 30 '14 at 14:24