Google Android - это несложно

Собственно - хочу включить в код обработку исключений. Но, поелику, ни разу еще этого не делал ни в одном языке (старался все предусмотреть), то возник вопрос о типичном наборе ситуаций, которые просто обязательно требуется обернуть в трау-кэтч. Ну и разумеется для каждой ситуации - набор исключений, которые надо обработать+КАК обработать...для меня пока еще не очень понятно, что за stacktrace...но обработку, похожую на if then - понять могу )))

то что считаеш может выкинуть ошибку/сломаться запихиваеш в try-catch, а вот какие exception нужно подбирать

Еще часть можно обрабатывать try-finally

rezak90 писал(а):

Код: Выделить всё

try{
//труляля
} catch(Exception) {}

то что считаеш может выкинуть ошибку/сломаться запихиваеш в try-catch, а вот какие exception нужно подбирать

Вот именно "то, что считаю", я и не знаю. Поэтому этот список и нужен, типичных ситуаций, когда что-нить может сломаться...

этот "список", хранится в голове (хз как объяснить ещё), и приходит скорее всего с опытом, когда программист уже знает на два-три шага вперёд что здесь возможна ошибка при каких либо ситуаций. Так что делай пока без него, потом тести прогу, увидишь ошибки уже делай выводы и включай всё в обработчики ошибок

Ну вот...у тебя в голове - а ты формализуй на форуме, напиши так:
1.Когда я пытаюсь делить на ноль | обработать ДелимНаНольИсключение | Обрабатываю так - выдаю мессагу и ретурном возвращаю к исходным данным
2.....
3....
4....

Я не думаю, что таких ситуаций навалом, но у каждого свой список точно есть. Если б вы его так формализовали, а админ его б подвесил в важные темы, то это сняло бы кучу вопросов у нубов. Да, понимаю, это надо потратить время, но учитывая, сколько ты и неокси уже тратите его на объяснение мне прописных истин (с вашей т.з. наверное детских вопросов), то наверное вы выделите его и для этой, в общем-то, весьма нужной штуки И уж точно, масса нубов будет очень благодарна за это

Согласен что это приходит с опытом, как я накапливаю этот опыт? Очень просто, в доках есть какие ошибки могут быть при использовании.
Например мы работаем с HttpClient, видим что он может "бросать" IOException и ClientProtocolException.
Вот так и запоминается это все

Finch писал(а):Согласен что это приходит с опытом, как я накапливаю этот опыт? Очень просто, в доках есть какие ошибки могут быть при использовании.
Например мы работаем с HttpClient, видим что он может "бросать" IOException и ClientProtocolException.
Вот так и запоминается это все

Отличный совет, не знал!

Но это все равно - немного не то )))

Открываем Хорстманна первый том "Основы Java". Там про обработку исключений написано, когда и как их обрабатывать, на какие 2 типа делятся исключения и как их лучше обрабатывать, где обрабатывать.
try catch подход удобен, но иногда лучше к примеру объявить в заголовке метода
public void someMethod() throws IOException {
...}
тогда мы в методе, где вызываем этот метод, можем отлавливать данный тип исключений. Т.е. проброс на более высокий уровень. А можно создавать свои исключения.
Хоть сам зачастую юзаю try catch, но всё же считаю это неверным делом. К примеру если пишите библиотеку, то там сам доктор прописал выбрасывать что-то другому программеру, ибо он должен понимать что творится.

Господа )))
Вопрос не в технологии обработки ))) А в том - в каких ситуациях это надо делать ))) См выше, я написал пример )))

В ситуациях, в которых невозможно на 100% гарантировать, что все будет хорошо. К примеру, запрос данных в интернете, парсинг данных и т.д.

neoksi писал(а):В ситуациях, в которых невозможно на 100% гарантировать, что все будет хорошо. К примеру, запрос данных в интернете, парсинг данных и т.д.

А в каких ситуациях нельзя на 100% гарантировать? )))) Сорри, это все общие слова, а нубам этого мало ))) Нам надо реальное описание )))

Не стесняемся, пишем, можно даже не писать словами, а выдрать кусок кода и сюда вставить - будет тогда понятно - ситуация, что обрабатывается и как )))

powercat
В том то и задача программиста, все предусмотреть, а исключения появляются тогда, когда невозможно четко гарантировать результат выполнения алгоритма.

П.С. С таким вектором обсуждения, тему пора отправлять во флудильню.

Да, предлагаю дождаться результатов - вдруг кто напишет )))

powercat писал(а):Господа )))
Вопрос не в технологии обработки ))) А в том - в каких ситуациях это надо делать ))) См выше, я написал пример )))

Неверно. Именно как надо делать, а не когда. Делать надо всегда!
1. Может быть null ? Пожалуйста, if else вам в помощь. почему не try catch? быстрее! Далее..
2. Клиент-серверное приложение на сокетах. Либо сервер, либо клиент рвет соединение (инет к примеру отвалился) и мы падаем в Exception без вопросов. throws или try catch ? или try finally?
try catch и finally. Почему так? Потому что нам надо в finally (именно тут обычно это делается) закрыть сокет, закрыть потоки. Еще есть такие вещи, как Хороший вариант выстрелить себе в ногу. Аналогично try-finally. Понимаю что что-то можно пропустить, ибо вы понимаете что и как. Но вот вам пример небольшой. Делал я как-то тестовое задание на работу и делал клиент-серверное решение как раз на сокетах. Сервер может работать в роли эха всем кому надо, а может и одному. Не столь важно. Важно то, что я в одном месте поступил так же и всё было замечательно. Но спустя двое суток, написания кучи кода, я сменил немного алгоритмы по мере надобности. В итоге при разрыве соединения, мой комп вёл себя неадекватно. Процессор ел на все 100. Всему виной было то исключение.
3. Парсинг данных. В документации true ? А на деле приходит True. И вот True совсем получается не true. Тут смысл о том, что нельзя всё предусмотреть. И тут следует думать о критичности места.
4. Допустим есть JSON объект с 10 параметрами. Нам либо 10, либо ничего. Что делать? Любой может быть null. В нашем условии один try catch всего парсинга с выводом в лог исключения.
А если нам нужны данные все, что возможны? Тогда я бы сделал if else всех мест, где парсится. Короче зависит от того, что нам от него нужно.
5. Классика! Нам нужен файл? Откуда? С флешки? Ок, идём туда. Читаем (100500 мегабайт), а тут флешка начинает кряхтеть. Что словим? Исключение. Но ведь нас не просят его отлавливать.
6. Коллекция объектов. Многопоточность. Один поток бежит итератором по коллекции, другой добавляет/удаляет элемент. Вот вам Exception.

Отлично, беру к себе в постоянные примеры.