Понял. Ну, с одной стороны, логично, конечно, унифицировать обработку ошибок. С другой — не очень прозрачно получится через NSError пропихивать конкретные типы, плохо он для этого приспособлен. Но мысль интересная, спасибо, как появится время, поэкспериментирую.
Предположим, что в случае успеха сервер возвращает json-структуру по ключу result, а в случае внутренней, семантической ошибки — error. В таком случае имеет смысл описать в IDL результат работы удалённого метода так:
После завершения вызова сгенерированный код извлечёт из ответа те структуры, которые там есть, и не проинициализирует те, данные для которых не пришли. Они останутся nil. То есть после вызова достаточно будет убедиться, что структура error не nil, чтобы получить информацию об ошибке. Кстати, этот момент описан в примере, прилагающемся к коду в репозитории.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
После завершения вызова сгенерированный код извлечёт из ответа те структуры, которые там есть, и не проинициализирует те, данные для которых не пришли. Они останутся nil. То есть после вызова достаточно будет убедиться, что структура error не nil, чтобы получить информацию об ошибке. Кстати, этот момент описан в примере, прилагающемся к коду в репозитории.