Class representing a text file

I'm trying to write a simple class to represent a text file - which one would think should be quite easy. I don't intend to add all bells and whistles to fully represent a text file just enough to be able create/open read and write etc.

The more I look at it the more I think that it's a bad idea or rather that I'm approaching it the wrong way. The main problem that stands out is the exception handling which horrible. I've thrown runtime exceptions for situations that if feel there is no other way to handle them there must be a better way to do this.

The getText() method throws a FileNotFoundException which is ugly for the caller - before this I handled it in the method and created a new file and returned an empty string which is worse, I think.

Initially I read in the text only once on construction and stored the string in a field which suited my needs better (I don't expect the file to be changed and continually having to read it in seems a bit inefficient) but later I decided that this didn't really correctly model a TextFile.

How can I improve this class that should represent a text file?

```
public class TextFile extends File{

private static final long serialVersionUID = 1L;

/**
* -Create a new textfile, with the supplied text
* -if the file already exists the text
* it will be replaced with supplied text
*
* @param pathname
* @param text
*/
public TextFile(String pathname, String text){
super(pathname);
if(!exists()) {
createNewTextFile();
}else {
try {
setText(text);
} catch (FileNotFoundException e) {
throw new RuntimeException(e);
}
}
}

/**
* -Creates a new text file
by opening the file pointed to by the supplied pathname
* -If the file doesn't exist a new empty text file will be created
*
* @param pathname
* @throws IOException
*/

-
I think you shouldn't use inheritance here. The java.io.File class is an abstract representation of file and directory pathnames (from the javadoc) and it has methods that a TextFile should not have: list, listFiles, mkdir, etc. Effective Java, 2nd Edition, Item 16: Favor composition over inheritance is a good source for this topic.

-
Instead of the read and write methods I'd use FileUtils.readFileToString and writeStringToFile or at least check (or copy) their source. "... take advantage of the knowledge of the experts who wrote it and the
experience of those who used it before you." (From Effective Java, 2nd Edition, Item 47: Know and use the libraries)

-
You should specify the charset when you create the OutputStreamWriter. The default could vary from system to system and you may loose non-ASCII characters.

-
Notice the difference between StringBuffer and StringBuilder: StringBuilder and StringBuffer in Java on Stack Overflow (The read method could use non-thread safe StringBuilder although FileUtils is better. You use the StringBuilders as local variables inside a method and currently they can't be accessed by other threads so it's enough to use non-thread-safe version.)

-
The code currently throws RuntimeExceptions on IO errors and RuntimeExceptions usually stops the whole application. A well-written application or library should handle disks without empty space and other IO errors, so I think throwing checked IOExceptions would be fine here. Further reading: Effective Java, 2nd Edition, Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors

StackExchange Code Review Q#15885, answer score: 7