Игра в прятки: кодогенерация против JSON

[not_ice]

Звучит интересно, надо попробовать :)
Такой вопрос интересует: если статусы ошибок реализованы не через статусы HTTP, а через специальное поле в json-ответе, как такие ошибки можно обрабатывать? Я так понимаю, в сгенерированный код методов лучше не лезть (имена переменных вроде outputResult237Address_components238 как бы намекают нам на это)?

[ptiz]

Предположим, что в случае успеха сервер возвращает json-структуру по ключу result, а в случае внутренней, семантической ошибки — error. В таком случае имеет смысл описать в IDL результат работы удалённого метода так:

...
"response": {
    "result": { ... },
    "error": { ... }
}

После завершения вызова сгенерированный код извлечёт из ответа те структуры, которые там есть, и не проинициализирует те, данные для которых не пришли. Они останутся nil. То есть после вызова достаточно будет убедиться, что структура error не nil, чтобы получить информацию об ошибке. Кстати, этот момент описан в примере, прилагающемся к коду в репозитории.

[not_ice]

Это в общем-то понятно, хотелось бы, чтобы метод placeDetailsWithKey записывал таккую ошибку в (NSError* )error.

[ptiz]

Понял. Ну, с одной стороны, логично, конечно, унифицировать обработку ошибок. С другой — не очень прозрачно получится через NSError пропихивать конкретные типы, плохо он для этого приспособлен. Но мысль интересная, спасибо, как появится время, поэкспериментирую.

[mishasamin]

Бедный ёжинька на картинке :(