CFNetwork все еще передает CFStreamErrors, хотя его не рекомендуется? - PullRequest
Новая
       23

CFNetwork все еще передает CFStreamErrors, хотя его не рекомендуется?

0 голосов
/ 12 февраля 2010

Я пишу некоторый код, который упаковывает некоторые вещи CFNetwork, чтобы выполнить разрешение DNS в Objective-C.

Все хорошо и работает, но у меня есть несколько вопросов:

Прототип функции обратного вызова для асинхронного разрешения CFHost передает ссылки на CFStreamError структуры, даже если в документации сказано, что CFStreamError устарело и вместо этого следует использовать CFReadStreamCopyError, что будет возвращать структуру CFError .

Функция обратного вызова объявлена ​​так: 

typedef void (CFHostClientCallBack) (
    CFHostRef theHost,
    CFHostInfoType typeInfo,
    const CFStreamError *error,
    void *info);

Похоже, нет альтернативы этому обратному вызову, который использует API, не подлежащие устареванию.

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

Основная проблема, с которой я столкнулся, заключается в том, что CFStreamErrors действительно неописуемые ... Могу ли я что-нибудь сделать, чтобы превратить CFStreamError в CFError?

Просто уточнить несколько моментов:

Не думаю, что я неправильно прочитал документацию по этому вопросу. метод обратного вызова, используемый в системе асинхронного разрешения CFHosts, передается в CFStreamError. Хотя CFStreamError сам по себе не может быть устаревшим, функции, которые его возвращают, а именно CFReadStreamGetError и CFWriteStreamGetError, являются устаревшими. Документация предлагает использовать CFReadStreamCopyError и CFWriteStreamCopyError, которые возвращают CFError вместо CFStreamError.

Я обертываю этот код в Objective-C и много использую объекты Foundation. таким образом, CFError гораздо более полезен для меня, чем CFStreamError, потому что он бесплатен, соединен с NSError, а CFStreamErrors не содержит почти столько полезной информации, сколько CFError. Более того, я даже не имею дело с CFStream напрямую, так почему я должен иметь дело с его конкретной структурой ошибок? Наконец, я хочу в конечном итоге вернуть NSError при вызове делегата обратно в мой класс-обертку.

Кроме того, я знаю, что устаревание не означает, что метод исчез, но если что-то помечено как устаревшее, было бы целесообразно (по крайней мере для меня) предоставить альтернативу. В противном случае устаревший метод / функция / класс и т. Д. По-прежнему используется, и нет смысла отрицать его, пока что-то не заменит его?

Ответы [ 2 ]

0 голосов
/ 18 февраля 2010

Структура CFStreamError фактически не рекомендуется. Из документации видно, что это будет в следующем выпуске (поскольку они не рекомендуют методы, которые его возвращают). На данный момент, однако, похоже, что вам все равно придется иметь дело с самой структурой, поскольку не было сделано никакого обратного вызова для замены.

Я понимаю, что это не тот тип ответа, который вы искали, но CFStreamError на самом деле еще не полностью устарел, поэтому у вас не будет замен для всех его применений.

0 голосов
/ 16 февраля 2010

Устаревший означает, что планируется устареть. Это предназначено для разработчиков программного обеспечения Apple, а также сторонних разработчиков программного обеспечения.

Кроме того, вы неправильно читаете документацию. Структура возвращается функцией CFReadStreamGetError . Документация предлагает новые функции API для использования, а не новую структуру ошибок для использования.

...