Переключение писателей на OutputStream в Java - PullRequest
4 голосов
/ 26 июня 2009

У меня есть один метод, который открывает файл и передает его другой функции, чтобы записать в нее некоторые данные. Этот второй метод хочет использовать PrintWriter для записи своих данных. Однако я не хотел требовать, чтобы все использовали PrintWriter для записи в этот поток.

В настоящее время это выглядит примерно так (санированный пример ... не надо критиковать мой выбор методов или имен переменных)

public void exportRawDataIntoStream(OutputStream os) {
    PrintWriter pr = new PrintWriter(os);
    printFirstData(pr);
    printSecondData(pr);
}

public void exportToFile(File file) {
    OutputStream os = null;
    try {
        os = new BufferedOutputStream(new FileOutputStream(file));
        exportRawDataIntoStream(os);
                doMoreWithTimeFile(os);
    } finally {
        if (os != null) {
            try {
                os.close();
            } catch (Exception e ) {
                e.printStackTrace();
            }
        }
    }
}

Это не сработает, если я не добавлю pr.flush в конце exportRawDataIntoStream. Я не могу закрыть PrintWriter, потому что это закрывает весь поток.

Является ли сбор данных законным и надежным? Есть ли какой-то другой подход, который я должен использовать, чтобы смешивать Writers в одном потоке, или я должен просто абсолютно никогда этого не делать?

1 Ответ

5 голосов
/ 26 июня 2009

Да, флеш должен быть надежным. Его основная роль - «выталкивать» любые лишние данные.

Однако, чтобы быть справедливым, это будет работать только с вашими основными писателями. Помните, я думаю, что это большинство, если не все, из них.

Но рассмотрим какой-нибудь придуманный особый вид писателя. Что-то, что «делает что-то еще» при закрытии. Как поток шифрования или сжатия.

Скажем, у вас был "писатель кодировщика base64", он не может безопасно написать потенциально завершающий "==", пока он не ГОТОВ, и это конец, а не сброс.

Но с этим предостережением для вашего случая с PrintWriter это не должно быть проблемой.

...