Программирую на Java под Android. И есть очень нехорошее свойство, что при малейшей нештатной ситуации программа закрывается (вылетает). Постоянно приходится добавлять try...catch (Попытка...Исключение), чтобы функция нормально отработала. Дошло уже до автоматизма, что пишу

public void f() {
try {
   здесь тело функции
} catch (Exception e) {
   Log.e(TAG, e.getMessage());
   e.printStackTrace();
}
}

Есть ли способ не уродовать каждую функцию, а сделать какую-то глобальную обработку ошибок?

Кроме того, не понимаю, зачем создавать собственный класс исключений? Ведь тогда моя ловушка может что-то не словить и нафиг она нужна?

Перед обращением к методу любого объекта надо проверять его на null, иначе выскакивает NullPointerException? Это вообще нормально?

Никто не знает?

Про исключения: типизированные или нет - эт одревний холивар

мне кажется к каждому случаю вылета нужно подходить отдельно

про null. Переходи на котлин, там с этим попроще

про котлин и null safety
http://kotlinlang.org/docs/reference/null-safety.html

(4) Да, я нашёл этого урода, который изобрёл Null Pointer
https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions

Поубывал бы...

мне кажется это одна из главных причин почему котлин вообще запилили

>>Перед обращением к методу любого объекта надо проверять его на null, иначе выскакивает NullPointerException

а в 1С разве не так, когда объект=Неопределено?

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

(0) В нетбинс есть даже функция автоподстановки глобального логгера. Вот в Андроид студио ее нет, но ты ее можешь сделать сам. Или как вариант объявляю каждую функцию Throwable с пробросом в класс-обрабочтик ошибок.

(1) В Джаве сборщик мусора удаляет все из хеап, если ссылки null, поэтому явно надо проверять на null.

Для интерпретируемых языков - это нормально, хотя и неудобно.

Нашёл полезные статьи
https://habrahabr.ru/company/mailru/blog/322416/
и продолжение https://habrahabr.ru/company/mailru/blog/322804/

1. Трайкатчить это плохо
2. 1С это зло (слишком расслабляет) для нормального программирования с предусматриванием всевозможных ситуаций чтобы штатно их отработать без ошибки.
3. Проверка на null это нормально, потому что по концепции ООП ты не знаешь что тебе передали, еще тип тоже проверять так то надо.

(13) по концепции ООП, реализованной в Java, типы вполне известны, но вот единственное уродливое значение null является любым типом

А способ кстати есть чтобы писать удобно ))
Это придумать (и написать) свою "мобильную платформу" ну или взять какую то готовую.

(14) Там есть засада с приведениями типов, к примеру
string b;
double a = (int)b;

(16) разве так можно в джаве?

ещё полезная статья https://habrahabr.ru/post/221243/
в ней упоминается некие "null-аннотации"
Это что-то типа @Nullable, @NonNull и @CheckResult
Пока ещё мало ими пользовался.

(0) Классы исключений нужны чтобы разные типы исключений обрабатывать по-разному. Например, если у тебя ошибка IO, то можно попытаться что-то сделать с файлом, а если деление на ноль, то это другая ситуация.

В java 8 появился "привет из Scala" – класс Optional (который, на самом деле, монада Maybe из Haskell). Он инкапсулирет проверку на nullpointer.

(20) О, интересно

(20) монада Maybe очень понравится девушкам-программистам. Надо рассказать жёнам ;)

Только под android java 8 не поддерживается.

(22) Гланое, монаду с мандой не перепутать, а так всё нормально.

(23) почитал про Optional https://habrahabr.ru/post/225641/
Что-то он меня не впечатлил. Пустые ссылки у себя я уже реализовал. В объектах "Справочник" и "Документ" есть метод isEmpty() (аналог 1с Пустая()). Можно ещё дополнить объекты "Справочник" и "Документ" всей этой галиматьёй из Optional.
И что-то не радует меня натыкивать кругом это Optional<MyClass>...

В любом случае получается, что нужно что-то натыкивать:
1) или проверки на null и try-catch
2) или optional,
3) или null-аннотации.
А может всё сразу натыкать?

(25) Выбора не много:
Otional ты не воткнешь. См.(23);
try catch дорогое удовольствие;
остается только проверять if'ами.
Аннотации - они больше для IDE и компилятора.

(26) fucking java... fucking android...

(27) В андроиде, оказывается, много полезных аннотаций http://developer.alexanderklimov.ru/android/studio/support-annotations.php

Вот прямо в тему https://habrahabr.ru/post/237843/

(28) Да-да. Я уже воспользовался аннотацией @Deprecated для собственных классов. Очень полезная штучка для рефакторинга. Перед непосредственным разрушением программы
1) ставишь аннотацию @Deprecated перед методом/классом/переменной, которые планируешь уничтожить/переместить.
2) делаешь Find Usages (Alt-F7). Все вызовы становятся зачёркнутыми. Справа в модулях появляются жёлтые метки.
3) проводишь рефакторинг, при котором код можно копировать и часто запускать. Добиваешься чистого кода. В итоге класс/метод/переменная, который пометил @Deprecated, должны стать серыми. Но подсветка может глючить, поэтому делаешь Find Usages и убеждаешься, что нет ссылок.
4) комментируешь старую сущность, делаешь контрольный запуск с прогоном тестов и удаляешь нахрен. Всё. Рефакторинг закончен.

(30) Кстати когда 1С то до этого дойдет вместо этих "Удалить..." ))

(31)+ в уже ненужных метаданных

(17) Нельзя конечно, просто пример привел, к примеру

String b = null;
double a = Integer.parseInt(b);

Прекрасно компилится и замечательно падает, ибо проверки на null нету...

А даже если и проверил на нулл то будь добр еще или проверь валидность внутри строки для преобразования в число ну или

String b = null;
double a;
try {
  a = Integer.parseInt(b);
} catch (NumberFormatException e) {
  System.out.println(e.toString());
}


(33) Я решил эту проблему просто: не пользуюсь Integer.
Мне хватает int

(0)Это чё миста на андроилд будет?

(35) Уже есть клиенты для форума на Андроиде. Ниша уже занята.

Чтобы ловить необработаные исключения, я делал так:

1. Создаем класс ExceptionHandler который реализует интерфейс: java.lang.Thread.UncaughtExceptionHandler

2.В методе onCreate каждой активности добавляем строчку:
Thread.setDefaultUncaughtExceptionHandler(new ExceptionHandler(this));

3.Для отображения ошибки рисуем свой layout activity_error.xml, с отображением stacktrace и кнопкой отправки разработчику.

Гайд:
https://github.com/hardik-trivedi/ForceClose

(37) Огромнейшее спасибо! Это громадный шаг в правильном направлении!