Исключения действительно для исключительных ошибок? [закрытый]
Ваш API возвращает JSON Object вместо JSONArray.
Проверьте разницу между этими двумя: Объект JSON против JSONArray
Хотя вы также можете работать с JSONObject, просто сделайте следующее:
String value = jsonObject.getString("key")
В случае вас используют Volley, тогда по умолчанию Volley возвращает ответ об успешном выполнении, анализируя его в JSONObject. Таким образом, jsonObject будет заменено на response.
10 ответов
Это звучит сверхупрощенным, но я думаю, что имеет смысл просто использовать исключения, где они являются соответствующими. На языках как Java и Python, исключения очень распространены, особенно в определенных ситуациях. Исключения подходят для типа ошибки, которую Вы хотите пузыриться через путь выполнения кода и вынудить разработчика явно зафиксировать. В моем собственном кодировании я полагаю, что правильное время добавляет исключение, когда ошибка или не может быть проигнорирована, или это просто более изящно для выдачи исключения вместо того, чтобы возвратить ошибочное значение к вызову функции и т.д.
Некоторые самые соответствующие места для исключений, о которых я могу думать бесцеремонно:
- NotImplementedException - очень соответствующий способ определять это конкретный метод или функция не доступны, вместо того, чтобы просто возвратиться, ничего не делая.
- исключения OutOfMemory - трудно вообразить лучший способ обработать этот тип ошибки, так как это представляет сбой выделения памяти всей ОС или всего процесса. Это важно для контакта с, конечно!
- NullPointerException - Доступ к пустой переменной является ошибкой программиста и IMO, это - другое хорошее место для принуждения ошибки пузыриться на поверхность
- , ArrayIndexException - На неумолимом языке как C, переполнение буфера имеет катастрофические последствия. Более Хорошие языки могли бы возвратить нулевое значение некоторого типа, или в некоторых реализациях, даже перенести массив. По-моему, выдача исключения является намного более изящным ответом.
Это ни в коем случае не всесторонний список, но надо надеяться он иллюстрирует тезис. Используйте исключения, где они изящны и логичны. Как всегда с программированием, правильный инструмент для правильного задания является хорошим советом. Нет никакого смысла идущего сумасшедший исключением ни для чего, но одинаково неблагоразумно полностью проигнорировать мощный и изящный инструмент в Вашем распоряжении.
Оператор от Krzysztof Cwalina немного вводит в заблуждение. Исходный оператор отсылает 'исключительные условия', для меня естественно, что я - тот, который определяет то, что является исключительным или нет. Тем не менее, я думаю сообщение, через которое проходят хорошо, так как я думаю, что мы все говорим об исключениях 'разработчика'.
Исключения являются большими для коммуникации, но с небольшим дизайном иерархии они являются также великими для некоторого разделения проблем, особенно между слоями (ДАО, Бизнес, и т.д.). Конечно, это только полезно при обработке этих исключений по-другому.
А хорошим примером иерархии является иерархия исключения доступа к данным пружины.
KCwalina имеет точку. Будет хорошо определить случаи, где код перестанет работать (до предела)
, я соглашаюсь с S.Lott, что иногда проверка лучше, чем выдать Исключение. Однако OutOfMemory не то, что Вы могли бы ожидать в своем приложении (если он не выделяет память большой емкости & память потребностей для хождения вперед).
я думаю, это зависит от домена приложения.
Я думаю, что существует несколько серьезных оснований, почему исключения должны использоваться для ловли неожиданных проблем.
Во-первых, они создают объект инкапсулировать исключение, которое по определению должно сделать его намного более дорогим, чем обработка простого оператора "if". Как пример Java, необходимо назвать File.exists () вместо того, чтобы обычно ожидать и обработать FileNotFoundException.
, Во-вторых, исключения, которые пойманы вне существующего метода (или возможно даже класс) делают код намного тяжелее, чтобы читать, чем если бы обработка - все там в в одном методе.
Однако я лично любовь исключения. Они освобождают Вас от потребности явной обработки всех тех ошибок типа may-happen-but-probably-never-will, которые заставляют Вас повторяющимся образом писать обработку print-an-error-and-abort-on-non-zero-return-code каждого вызова метода.
Моя нижняя строка..., если можно обоснованно ожидать, что это произойдет затем, это - часть приложения, и необходимо кодировать для него. Что-либо еще - исключение.
Так как я обычно программа в Python, и в том языке, который исключения везде мне исключение, могу представить что-либо от системной ошибки до абсолютно законного условия.
, Например, "pythonic" способ проверить, содержит ли строка целое число, состоит в том, чтобы попробовать интервал (контрольное кольцо) и видеть, повышает ли это исключение. Это - "исключительная ошибка"?
Снова, в Python для цикла всегда считается действующий на итератор, и итератор должен повысить исключение 'StopIteration', когда это заканчивается, его задание (для цикла ловит то исключение). Это "Исключительно" каким-либо образом?
Я думаю, чем ближе к земле Вы, тем менее соответствующие исключения как средство ошибочного сообщения становятся. При более высокой абстракции такой как в Java или .NET, исключение может сделать для изящного способа передать сообщения об ошибках Вашим вызывающим сторонам. Это однако не имеет место в C. Это - также платформа по сравнению с проектным решением API.
Если Вы практикуете, "говорят, не спрашивайте", что затем исключением является просто способ, которым в программе говорится, что "Я не могу сделать этого". Это "исключительно" в этом, Вы говорите, "делают X", и это не может сделать X. Простая ситуация обработки ошибок. На некоторых языках довольно распространено проложить себе путь в Java, и у людей C++ есть другие мнения, потому что исключения становятся довольно дорогостоящими.
Общий: исключение просто означает, что "Я не могу"
Прагматичный:..., если можно позволить себе проложить себе путь на языке.
Гражданство:... и Ваша команда позволяет его.
Действительно трудно знать то, что точно толкует "исключительное условие", которое гарантирует использование исключения в программе.
Один экземпляр, который очень полезен для использования передача причины ошибок . Поскольку кавычка от Krzysztof Cwalina упоминает:
Одно из самых больших неправильных представлений об исключениях - то, что они для “exceptional условий. ”, который действительность - то, что они для передачи состояний ошибки.
Для предоставления конкретного примера скажите, что мы имеем getHeader(File f) метод, который читает некоторый заголовок из файла и возвращается FileHeader объект.
может быть несколько проблем, которые могут явиться результатом попытки считать данные с диска. Возможно, указанный файл не существует, файл содержит данные, которые не могут быть считаны, неожиданные ошибки доступа к диску, исчерпав память, и т.д. Имение нескольких средств отказа означает, что должно быть несколько способов сообщить, что пошло не так, как надо.
, Если исключения не использовались, но была потребность передать вид ошибки, которая произошла с подписью существующего метода, лучшее, которое мы можем сделать, должно возвратиться null. Начиная с получения null не очень информативно, лучшая коммуникация, которую мы получаем от того результата, - то, что "некоторая ошибка произошла, таким образом, мы не могли продолжить, извините". - Это не передает причину ошибки.
(Или альтернативно, у нас могут быть константы класса для объектов FileHeader, которые указывают на условия FileNotFound и такой, эмулируя коды ошибок, но это действительно сильно пахнет наличием булева типа с [1 110] TRUE, FALSE, FILE_NOT_FOUND .)
, Если мы добрались FileNotFound или DeviceNotReady (гипотетическое) исключение, по крайней мере, мы знаем то, чем источник ошибки был, и если бы это было приложением конечного пользователя, то мы могли бы обработать ошибку способами решить проблему.
Используя механизм исключения дает средство сообщения, которое не требует нейтрализации к использованию кодов ошибок для уведомления об условиях, которые не являются в нормальном потоке выполнения.
Однако, который не означает, что все должно быть обработано исключениями. Как указано [1 111] S.Lott:
не используют исключения для проверки ввода данных пользователем, например. Люди делают ошибки все время. Это - то, для чего операторы "if".
Это - одна вещь, которая не может быть подчеркнута достаточно. Одной из опасностей не знания, когда точно использовать исключения, является тенденция пойти счастливая исключением; использование исключений, где контроль ввода был бы достаточен.
нет действительно никакого смысла в определении и броске InvalidUserInput исключение, когда все, что требуется, чтобы иметь дело с такой ситуацией, должно уведомить пользователя того, что ожидается, как введено.
кроме того, нужно отметить, что ввод данных пользователем , ожидал иметь дефектный вход в какой-то момент. Это - защитная мера для проверки входа перед передачей входа от внешнего мира до внутренностей программы.
немного трудно решить то, что является исключительным и что не.
Для людей, которые пишут платформы, возможно, это интересно.
Для остальной части нас, это путает (и возможно бесполезный.) Для обычных приложений исключения должны быть обойдены как "исключительные" ситуации. Исключения прерывают обычную последовательную презентацию Вашей программы.
необходимо быть осмотрительными о повреждении обычной последовательной обработки от начала до конца программы. Обработка исключений - намеренно - трудно для чтения. Поэтому зарезервируйте исключения для вещей, которые являются вне стандартных сценариев.
Пример: не используйте исключения для проверки ввода данных пользователем. Люди делают входные ошибки все время. Это не исключительно, вот почему мы пишем программное обеспечение. Это - то, для чего операторы "if".
, Когда Ваше приложение получает исключение OutOfMemory, нет никакого смысла в ловле его. Это исключительно. "Последовательное выполнение" предположение из окна. Ваше приложение обречено, просто откажите и надейтесь, что Ваша транзакция RDBMS заканчивается перед катастрофическим отказом.
Я задавался вопросом об этом сам. Под чем мы подразумеваем "исключительный"? Возможно, нет никакого строгого определения, но не там никакие эмпирические правила, которые мы можем использовать для решения то, что является исключительным в данном контексте?
, Например, справедливости ради стоило бы отметить, что "исключительное" условие является тем, которое нарушает контракт функции?