That was originally intended this way (documentation is lacking).

The idea was to provide getters for the equivalent setters. If no output stream was set excplicitly, the method returns NULL.

Creating an output stream within the method leads to memory ownership questions. This can be discussed but we should not just change it without thinking about the implications for the API and users.

We added this information in the documentation and we will close this bug after merging.

I think this might need to be discussed. Instead of closing just set the target milestone to after next release and leave it open.

User wildes has pushed new remote branch:

bug-18252-DocumentationOfAbstractFileWriter

Some additional information on the intended usage:

Writers (and analogous readers) can have a stream or a file name set (or both, then the one set last wins, I think). The writer (reader) implementation should not check this condition itself (e.g. by testing the result of GetOutputStream() for nullptr) but use the provided utility classes OutputStream (InputStream) and LocalFile. If a writer's implementation can write to streams (this is the ideal case), it should instantiate a local OutputStream object and just write to it. If it needs a file system path (e.g. because it internally uses another class, maybe from another toolkit, which requires a file name), a local LocalFile object should be created, which can then be used to retrieve a path in the local file system to write to (or read from for readers).

These helper classes will do the right thing, depending on the externally set output / input stream (which can be null) or file name.

Esther what is the status of this bug?
Did you talk to sascha regarding his last comment?
I think it does make sense to add sascha last comment to the documentation.