Try and catch in android

Исключения: try/catch/finally/throw

Обработка исключений устроена так же, как в Java. Функция может завершиться обычным способом или возбудить исключение в случае ошибки. При вызове функции можно перехватить исключение и обработать его. Можно пропустить обработку, тогда исключение продолжит своё движение вверх по стеку.

Ключевое слов throw можно использовать как выражение в составе других выражений.

Можно использовать выражение с try/catch/finally. Напишем функцию чтения строки из файла и преобразования её в строку. В успешном случае возвращается число или null, если строка не является числом.

Ключевое слово try можно использовать как выражение. Изменим функцию и добавим код, выводящий число, прочитанное из файла.

В блоке catch находится оператор return, поэтому выполнение функции прервётся после выполнения блока catch. Если нужно, чтобы функция продолжила выполнение после выхода из блока catch, нужно вернуть значение последнего выражения.

В этом случае возникнет исключение и возвратится null. Если бы строка содержала число, то выражение в try станет результатом.

Можно создавать собственные типы исключений, используя суперкласс Exception.

Функция printStackTrace() доступна для всех исключений, выполняемых в JVM. Если вы не можете восстановить работу программы после исключения, функция printStackTrace() поможет выявить причину проблемы.

Источник

Try-catch v/s Null-check in Android.

I believe most of the productive developers are the lazy ones 🤣 . Most of us uses JSON2POJO , ButterKnife etc. to save time. No doubt , it’s good. But sometimes that laziness can slow down your app.

What we know about Try-catch ?

Once in an Interview with a fresher, I asked about try-catch and got funniest reply —

we put that code in try<> that we are afraid of it might be null or it can cause app crash & we catch error in catch<>.

But we can never catch Errors 😒 . Mostly newbies mistakenly takes Errors & Exceptions as same . Well , We were talking about Try-catch and Null Check.

In practice I see exception often used out of laziness. Instead of properly handling an error condition at the location where it occurs, people find it easier to throw an exception and catch it somewhere downstream, often resulting in spitting out some incomprehensible error message to the user.

Performance :

Clemens Vasters tweets some time ago —

Below we can see what happen when we write →

Exceptions do take extra memory, as well as time, to catch. It is ALWAYS better to test for null if it’s a possible value. Another thing to consider it that it’s simply less code and more readable to do the null test. Usually having try/catch blocks adds essentially no overhead to your code for the normal case, but when the exception is triggered it’s quite expensive.

So what do we learned from above ? In one line —

Exceptions are, as their name implies, to be used only for exceptional conditions, they should never be used for ordinary control flow.

Moral ?

There are thousands cases where your code can go wrong: cannot connect to database, IO Exception, Network error… If you deal with them one by one (like the null check here), it would be too much of a hassle

but, if you know that variable/object can be null or it can cause a NullPointerException so better is to check rather than showing laziness (Ctrl+alt+t+6) 💻 ( try-catch shortcut in Android Studio) 😜

Источник

Try catch Java: Exception handling explained

Error handling, also called exception handling, is a big part of Java, but it’s also one of the more divisive elements. Exception handling allows a developer to anticipate problems that may arise in their code to prevent them from causing issues for users down the line. The reason this can become a nuisance is that some methods in Java will actually force the user to handle exceptions. This is where “try catch” in Java comes into play.

What is “try catch” Java?

For someone new to programming, it can be hard to understand why you might write code that makes it possible for an error to occur.

A good example would be the FileNotFoundException. This does exactly what it says on the tin: this exception is “thrown” when Java looks for a particular file and can’t find it.

So, what happens if someone is using your app, switches to their file browser, then deletes a save-file that the app was using? In that scenario, your application might understandably throw an exception. We say that this is an exception rather than an error because it’s a problem that we might reasonably anticipate and handle.

So you use a “try catch” block.

Try essentially asks Java to try and do something. If the operation is successful, then the program will continue running as normal. If it is unsuccessful, then you will have the option to reroute your code while also making a note of the exception. This happens in the “catch” block.

Try catch Java example

Here’s an example of using try catch in Java:

Here, we create a list with 6 entries. The highest index is therefore 5 (seeing as “1” is at index 0). We then try to get the value from index 10.

Try running this and you will see the message “Oops!”.

Notice that we passed “Exception e” as an argument. That means we can also say:

We will get the message: “java.lang.ArrayIndexOutOfBoundsException: 10”

Now that we have “handled” our exception, we can refer to it as a “checked exception.”

Forced exception handling

Notice that we could have written this code without handling the exception. This would cause the program to crash, but that’s our prerogative!

In other cases, a method will force the user to handle an exception.

So, let’s say that we create a little method that will check the tenth position of any list we pass in as an argument:

This works just fine and will print “11” to the screen. But if we add the “throws” keyword to our method signature, we can force the user to deal with it.

Now we can write our code like so:

This will then force the user to deal with the exception. In fact, many Java editors will automatically populate the code with the necessary block. Note that we need to use the right type of exception!

So, should you force other devs to handle exceptions when writing your own classes? That’s really up to you. Keep in mind that some scenarios really should cause a program to terminate, and forcing a developer to deal with such instances will only create more boilerplate code. In other cases, this can be a useful way to communicate potential issues to other devs and promote more efficient code.

Of course, in the example given here, there are a number of other possibilities for exceptions. What happens if someone passes a list of strings into your method, for example? All I can say to that is, welcome to the wonderful world of Java!

This is your chance to decide what type of developer you want to be! Once you’re ready to find out, check out our guide to the best resources to learn Java!

Источник

Avoid try/catch on Android

I am new in Android environment and I have started writing some code to execute some queries on a database. When I have to handle exceptions I don’t know what the appropriate way is to do it — out of Android I used to use throws declaration on methods but it seems that throws isn’t allowed in android? Just try-catch ? I say this because eclipse doesn’t suggest me adding throws declaration like when I am out of Android environment, I guess that it is related to extends Activity . So what is the appropriate way to handle exceptions in android? Surrounding every sentence with try-catch makes my code look terrible and that’s not really what I want to do.

3 Answers 3

If the method you are using already throws an exception, you may want to just re-throw the exception as the new type:

The other option is to make MyException extend RuntimeException . Then the compiler won’t force you to catch it or add it to the method signature. RuntimeExceptions are known as unchecked exceptions meaning you don’t have to check for them occurring by way of a try/catch. Examples of these are NullPointer and ArrayOutOfBounds .

I just was wondering about some strange handling of «throws» in Android environment and found this old question here. Asker Jon «started writing some code to execute some querys on a database», so maybe he noticed the same as I did.

This compiles without error:

Despite this declaration (in javadoc popup):

So first, monkjack is right when he points out that onCreate method’s signature cannot be changed by inheriting implementations. And second, Zeki is correctly indicating the difference between checked and unchecked exceptions.

And now third, I want to add that the big confusion is caused by SQLException .

Источник

Исключения в Java, Часть I (try-catch-finally)

Это первая часть статьи, посвященной такому языковому механизму Java как исключения (вторая (checked/unchecked) вот). Она имеет вводный характер и рассчитана на начинающих разработчиков или тех, кто только приступает к изучению языка.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

1. Ключевые слова: try, catch, finally, throw, throws

Механизм исключительных ситуаций в Java поддерживается пятью ключевыми словами

• try
• catch
• finally
• throw
• throws

«Магия» (т.е. некоторое поведение никак не отраженное в исходном коде и потому неповторяемое пользователем) исключений #1 заключается в том, что catch, throw, throws можно использовать исключительно с java.lang.Throwable или его потомками.

throws:
Годится

catch:
Годится

throw:
Годится

Кроме того, throw требуется не-null аргумент, иначе NullPointerException в момент выполнения

throw и new — это две независимых операции. В следующем коде мы независимо создаем объект исключения и «бросаем» его

Однако, попробуйте проанализировать вот это

2. Почему используем System.err, а не System.out

System.out — buffered-поток вывода, а System.err — нет. Таким образом вывод может быть как таким

Так и вот таким (err обогнало out при выводе в консоль)

Давайте это нарисуем

когда Вы пишете в System.err — ваше сообщение тут же выводится на консоль, но когда пишете в System.out, то оно может на какое-то время быть буферизированно. Stacktrace необработанного исключение выводится через System.err, что позволяет им обгонять «обычные» сообщения.

3. Компилятор требует вернуть результат (или требует молчать)

Если в объявлении метода сказано, что он возвращает НЕ void, то компилятор зорко следит, что бы мы вернули экземпляр требуемого типа или экземпляр типа, который можно неявно привести к требуемому

вот так не пройдет (другой тип)

Вот так не выйдет — нет возврата

и вот так не пройдет (компилятор не может удостовериться, что возврат будет)

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

Из-забавного, можно ничего не возвращать, а «повесить метод»

Тут в d никогда ничего не будет присвоено, так как метод sqr повисает

Компилятор пропустит «вилку» (таки берем в квадрат ИЛИ висим)

Но механизм исключений позволяет НИЧЕГО НЕ ВОЗВРАЩАТЬ!

Итак, у нас есть ТРИ варианта для компилятора

Но КАКОЙ ЖЕ double вернет функция, бросающая RuntimeException?
А НИКАКОЙ!

Подытожим: бросаемое исключение — это дополнительный возвращаемый тип. Если ваш метод объявил, что возвращает double, но у вас нет double — можете бросить исключение. Если ваш метод объявил, что ничего не возвращает (void), но у вам таки есть что сказать — можете бросить исключение.

Давайте рассмотрим некоторый пример из практики.

Задача: реализовать функцию, вычисляющую площадь прямоугольника

важно, что задание звучит именно так, в терминах предметной области — «вычислить площадь прямоугольника», а не в терминах решения «перемножить два числа»:

Вопрос: что делать, если мы обнаружили, что хотя бы один из аргументов — отрицательное число?
Если просто умножить, то мы пропустили ошибочные данные дальше. Что еще хуже, возможно, мы «исправили ситуацию» — сказали что площадь прямоугольника с двумя отрицательными сторонами -10 и -20 = 200.

Мы не можем ничего не вернуть

Можно, конечно, отписаться в консоль, но кто ее будет читать и как определить где была поломка. При чем, вычисление то продолжится с неправильными данными

Можно вернуть специальное значение, показывающее, что что-то не так (error code), но кто гарантирует, что его прочитают, а не просто воспользуются им?

Можем, конечно, целиком остановить виртуальную машину

Но «правильный путь» таков: если обнаружили возможное некорректное поведение, то
1. Вычисления остановить, сгенерировать сообщение-поломку, которое трудно игнорировать, предоставить пользователю информацию о причине, предоставить пользователю возможность все починить (загрузить белье назад и повторно нажать кнопку старт)

4. Нелокальная передача управления (nonlocal control transfer)

Механизм исключительных ситуация (исключений) — это механизм НЕЛОКАЛЬНОЙ ПЕРЕДАЧИ УПРАВЛЕНИЯ.
Что под этим имеется в виду?
Программа, в ходе своего выполнения (точнее исполнения инструкций в рамках отдельного потока), оперирует стеком («стопкой») фреймов. Передача управления осуществляется либо в рамках одного фрейма

и другие операторы.

Либо передача управления происходит в «стопке» фреймов между СОСЕДНИМИ фреймами

• вызов метода: создаем новый фрейм, помещаем его на верхушку стека и переходим в него
• выход из метода: возвращаемся к предыдущему фрейму (через return или просто кончились инструкции в методе)

return — выходим из ОДНОГО фрейма (из фрейма #4(метод h()))

throw — выходим из ВСЕХ фреймов

При помощи catch мы можем остановить летящее исключение (причина, по которой мы автоматически покидаем фреймы).
Останавливаем через 3 фрейма, пролетаем фрейм #4(метод h()) + пролетаем фрейм #3(метод g()) + фрейм #2(метод f())

Обратите внимание, стандартный сценарий работы был восстановлен в методе main() (фрейм #1)

Останавливаем через 2 фрейма, пролетаем фрейм #4(метод h()) + пролетаем фрейм #3(метод g())

Останавливаем через 1 фрейм (фактически аналог return, просто покинули фрейм «другим образом»)

Итак, давайте сведем все на одну картинку

5. try + catch (catch — полиморфен)

Напомним иерархию исключений

То, что исключения являются объектами важно для нас в двух моментах
1. Они образуют иерархию с корнем java.lang.Throwable (java.lang.Object — предок java.lang.Throwable, но Object — уже не исключение)
2. Они могут иметь поля и методы (в этой статье это не будем использовать)

По первому пункту: catch — полиморфная конструкция, т.е. catch по типу Parent перехватывает летящие экземпляры любого типа, который является Parent-ом (т.е. экземпляры непосредственно Parent-а или любого потомка Parent-а)

Даже так: в блоке catch мы будем иметь ссылку типа Exception на объект типа RuntimeException

catch по потомку не может поймать предка

catch по одному «брату» не может поймать другого «брата» (Error и Exception не находятся в отношении предок-потомок, они из параллельных веток наследования от Throwable)

По предыдущим примерам — надеюсь вы обратили внимание, что если исключение перехвачено, то JVM выполняет операторы идущие ПОСЛЕ последних скобок try+catch.
Но если не перехвачено, то мы
1. не заходим в блок catch
2. покидаем фрейм метода с летящим исключением

А что будет, если мы зашли в catch, и потом бросили исключение ИЗ catch?

В таком случае выполнение метода тоже прерывается (не печатаем «3»). Новое исключение не имеет никакого отношения к try-catch

Мы можем даже кинуть тот объект, что у нас есть «на руках»

И мы не попадем в другие секции catch, если они есть

Обратите внимание, мы не напечатали «3», хотя у нас летит Error а «ниже» расположен catch по Error. Но важный момент в том, что catch имеет отношение исключительно к try-секции, но не к другим catch-секциям.

Как покажем ниже — можно строить вложенные конструкции, но вот пример, «исправляющий» эту ситуацию

6. try + catch + catch + .

Как вы видели, мы можем расположить несколько catch после одного try.

Но есть такое правило — нельзя ставить потомка после предка! (RuntimeException после Exception)

Ставить брата после брата — можно (RuntimeException после Error)

Как происходит выбор «правильного» catch? Да очень просто — JVM идет сверху-вниз до тех пор, пока не найдет такой catch что в нем указано ваше исключение или его предок — туда и заходит. Ниже — не идет.

Выбор catch осуществляется в runtime (а не в compile-time), значит учитывается не тип ССЫЛКИ (Throwable), а тип ССЫЛАЕМОГО (Exception)

7. try + finally

finally-секция получает управление, если try-блок завершился успешно

finally-секция получает управление, даже если try-блок завершился исключением

finally-секция получает управление, даже если try-блок завершился директивой выхода из метода

finally-секция НЕ вызывается только если мы «прибили» JVM

System.exit(42) и Runtime.getRuntime().exit(42) — это синонимы

И при Runtime.getRuntime().halt(42) — тоже не успевает зайти в finally

exit() vs halt()
javadoc: java.lang.Runtime#halt(int status)
… Unlike the exit method, this method does not cause shutdown hooks to be started and does not run uninvoked finalizers if finalization-on-exit has been enabled. If the shutdown sequence has already been initiated then this method does not wait for any running shutdown hooks or finalizers to finish their work.

Однако finally-секция не может «починить» try-блок завершившийся исключение (заметьте, «more» — не выводится в консоль)

Трюк с «if (true) <. >» требуется, так как иначе компилятор обнаруживает недостижимый код (последняя строка) и отказывается его компилировать

И finally-секция не может «предотвратить» выход из метода, если try-блок вызвал return («more» — не выводится в консоль)

Однако finally-секция может «перебить» throw/return при помощи другого throw/return

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

Например для освобождения захваченной блокировки

Или для закрытия открытого файлового потока

Специально для этих целей в Java 7 появилась конструкция try-with-resources, ее мы изучим позже.

Вообще говоря, в finally-секция нельзя стандартно узнать было ли исключение.
Конечно, можно постараться написать свой «велосипед»

Не рекомендуемые практики
— return из finally-секции (можем затереть исключение из try-блока)
— действия в finally-секции, которые могут бросить исключение (можем затереть исключение из try-блока)

8. try + catch + finally

Не заходим в catch, заходим в finally, продолжаем после оператора

Есть исключение и есть подходящий catch

Заходим в catch, заходим в finally, продолжаем после оператора

Есть исключение но нет подходящего catch

Не заходим в catch, заходим в finally, не продолжаем после оператора — вылетаем с неперехваченным исключением

9. Вложенные try + catch + finally

Операторы обычно допускают неограниченное вложение.
Пример с if

Суть в том, что try-cacth-finally тоже допускает неограниченное вложение.
Например вот так

Или даже вот так

Ну что же, давайте исследуем как это работает.

Вложенный try-catch-finally без исключения

Мы НЕ заходим в обе catch-секции (нет исключения), заходим в обе finally-секции и выполняем обе строки ПОСЛЕ finally.

Вложенный try-catch-finally с исключением, которое ПЕРЕХВАТИТ ВНУТРЕННИЙ catch

Мы заходим в ПЕРВУЮ catch-секцию (печатаем «3»), но НЕ заходим во ВТОРУЮ catch-секцию (НЕ печатаем «6», так как исключение УЖЕ перехвачено первым catch), заходим в обе finally-секции (печатаем «4» и «7»), в обоих случаях выполняем код после finally (печатаем «5»и «8», так как исключение остановлено еще первым catch).

Вложенный try-catch-finally с исключением, которое ПЕРЕХВАТИТ ВНЕШНИЙ catch

Мы НЕ заходим в ПЕРВУЮ catch-секцию (не печатаем «3»), но заходим в ВТОРУЮ catch-секцию (печатаем «6»), заходим в обе finally-секции (печатаем «4» и «7»), в ПЕРВОМ случае НЕ выполняем код ПОСЛЕ finally (не печатаем «5», так как исключение НЕ остановлено), во ВТОРОМ случае выполняем код после finally (печатаем «8», так как исключение остановлено).

Вложенный try-catch-finally с исключением, которое НИКТО НЕ ПЕРЕХВАТИТ

Мы НЕ заходим в ОБЕ catch-секции (не печатаем «3» и «6»), заходим в обе finally-секции (печатаем «4» и «7») и в обоих случаях НЕ выполняем код ПОСЛЕ finally (не печатаем «5» и «8», так как исключение НЕ остановлено), выполнение метода прерывается по исключению.

Контакты

Я занимаюсь онлайн обучением Java (вот курсы программирования) и публикую часть учебных материалов в рамках переработки курса Java Core. Видеозаписи лекций в аудитории Вы можете увидеть на youtube-канале, возможно, видео канала лучше систематизировано в этой статье.

Мой метод обучения состоит в том, что я

1. показываю различные варианты применения
2. строю усложняющуюся последовательность примеров по каждому варианту
3. объясняю логику двигавшую авторами (по мере возможности)
4. даю большое количество тестов (50-100) всесторонне проверяющее понимание и демонстрирующих различные комбинации
5. даю лабораторные для самостоятельной работы

Данная статье следует пунктам #1 (различные варианты) и #2(последовательность примеров по каждому варианту).

Источник