Obj-C: NSError в инициализаторе

Достаточно простой вопрос:

У меня есть метод init в моем классе, который может пойти не так. Если это произойдет, я планирую «вернуть nil», но я также хотел бы вернуть ошибку. Является ли плохой практикой использование параметра NSError** для метода инициализации? Мое объявление метода будет выглядеть так:

- (id) initWithArgs:(NSString*) args andError:(NSError**)error;

Большое спасибо, Ник


person dark_perfect    schedule 24.03.2012    source источник


Ответы (1)


Это необычно, но я не думаю, что это обязательно плохая практика. Я бы назвал вторую часть метода просто «ошибка» вместо «andError:». Вам не нужно соединять части имени метода с помощью «и», и в этом случае также создается впечатление, что ошибка используется для инициализации объекта. Просто сделайте это:

- (id) initWithArgs:(NSString*) args error:(NSError**)error;

Кроме того, не забудьте освободить выделенный объект, если вы планируете вернуть что-то еще (например, nil):

- (id) initWithArgs:(NSString*) args error:(NSError**)error
{
    if ((self = [super init])) {
        if (canInitThisObject) {
            // init this object
        }
        else {
            [self release];
            self = nil;
            if (error != nil) {
                *error = [NSError errorWithDomain:someDomain code:someCode: userInfo:nil];
            }
        }
    }
    return self;
}
person Caleb    schedule 25.03.2012
comment
Одна вещь, которую я бы порекомендовал, это ВСЕГДА устанавливать для ошибки значение nil в начале метода. Нет никакой гарантии, что вызывающая сторона обнулит его. - person EricS; 25.03.2012
comment
@EricS Нет причин устанавливать error на nil, если нет ошибки. Вызывающий никогда не должен смотреть на значение @error, если метод не возвращает nil. В противном случае это ошибка. @Caleb, этот код необходимо проверить, чтобы убедиться, что error не равно NULL, прежде чем назначать *error. - person bbum; 25.03.2012
comment
По моему опыту, любое предложение, начинающееся с вызывающего абонента, обычно приводит к катастрофе. :-) - person EricS; 25.03.2012
comment
Конечно, но это не меняет правил. - person bbum; 25.03.2012
comment
В эпоху Swift 2 вы можете сохранить andError или использовать withError - person uchuugaka; 09.11.2015
comment
Я возражаю против рекомендации EricS. Поведение обработки ошибок от Apple говорит НЕ изменять *error, если не произошла ошибка, и входящая ошибка может указывать на предыдущую ошибку, которая произошла до этого вызова - не очищайте ее. - person Motti Shneor; 21.03.2021