Ошибка генерации тестовой подписи java lang nullpointerexception

Hey Geeks, today we will see what NullPointerException means and how we can fix it in Android Studio. To understand NullPointerException, we have to understand the meaning of Null.

What is null?

“null” is a very familiar keyword among all the programmers out there. It is basically a Literal for Reference datatypes or variables like Arrays, Classes, Interfaces, and Enums. Every primitive data type has a default value set to it(Ex: True and False value for Boolean). Similarly, Reference Datatype Variables have Null value as default if it is not initialized during declaration.

Output: 

null

It is also important to note that we cannot directly store a null value in a primitive variable or object as shown below.

Output:

Main.java:5: error: incompatible types:  cannot be converted to int
        int i = null;
                ^
1 error

What is NullPointerException?

It is a run-time exception that arises when an application or a program tries to access the object reference(accessing methods) which has a null value stored in it. The null value gets stored automatically in the reference variable when we don’t initialize it after declaring as shown below.  

 Output:

Exception in thread "main" java.lang.NullPointerException                                                                                      
        at Main.main(Main.java:6)  

Null Pointer Exception in Android Studio

NullPointerException in Android Studio highlighted in yellow color in the below screenshot 

As you can observe from the above picture, it contains a Textview which is initialized to null. 

TextView textview = null;

The TextView reference variable(i.e. textview) is accessed which gives a NullPointerException.

textview.setText("Hello world");

Code

Handling the NullPointerException in Android Studio

To Handle the NullPointerException smoothly without making the app crash, we use the “Try – Catch Block” in Android.

• Try: The Try block executes a piece of code that is likely to crash or a place where the exception occurs.
• Catch: The Catch block will handle the exception that occurred in the Try block smoothly(showing a toast msg on screen) without letting the app crash abruptly.

The structure of Try -Catch Block is shown below

Code

Output:

Using Try Catch we can catch the exception on the screen

How to fix the NullPointerException?

To avoid NullPointerException we have to initialize the Textview component with the help of findviewbyid( ) method as shown below. The findViewbyId( ) takes the “id” value of the component as the parameter. This method helps locate the component present in the app. 

Code

Output:

As you can see after initializing the text view component we have solved the NullPointerException. Hence in this way, we can get rid of NullPointerException in Android Studio.

Hey Geeks, today we will see what NullPointerException means and how we can fix it in Android Studio. To understand NullPointerException, we have to understand the meaning of Null.

What is null?

“null” is a very familiar keyword among all the programmers out there. It is basically a Literal for Reference datatypes or variables like Arrays, Classes, Interfaces, and Enums. Every primitive data type has a default value set to it(Ex: True and False value for Boolean). Similarly, Reference Datatype Variables have Null value as default if it is not initialized during declaration.

Output: 

null

It is also important to note that we cannot directly store a null value in a primitive variable or object as shown below.

Output:

Main.java:5: error: incompatible types:  cannot be converted to int
        int i = null;
                ^
1 error

What is NullPointerException?

It is a run-time exception that arises when an application or a program tries to access the object reference(accessing methods) which has a null value stored in it. The null value gets stored automatically in the reference variable when we don’t initialize it after declaring as shown below.  

 Output:

Exception in thread "main" java.lang.NullPointerException                                                                                      
        at Main.main(Main.java:6)  

Null Pointer Exception in Android Studio

NullPointerException in Android Studio highlighted in yellow color in the below screenshot 

As you can observe from the above picture, it contains a Textview which is initialized to null. 

TextView textview = null;

The TextView reference variable(i.e. textview) is accessed which gives a NullPointerException.

textview.setText("Hello world");

Code

Handling the NullPointerException in Android Studio

To Handle the NullPointerException smoothly without making the app crash, we use the “Try – Catch Block” in Android.

• Try: The Try block executes a piece of code that is likely to crash or a place where the exception occurs.
• Catch: The Catch block will handle the exception that occurred in the Try block smoothly(showing a toast msg on screen) without letting the app crash abruptly.

The structure of Try -Catch Block is shown below

Code

Output:

Using Try Catch we can catch the exception on the screen

How to fix the NullPointerException?

To avoid NullPointerException we have to initialize the Textview component with the help of findviewbyid( ) method as shown below. The findViewbyId( ) takes the “id” value of the component as the parameter. This method helps locate the component present in the app. 

Code

Output:

As you can see after initializing the text view component we have solved the NullPointerException. Hence in this way, we can get rid of NullPointerException in Android Studio.

Когда вы объявляете переменную ссылочного типа, на самом деле вы создаете ссылку на объект данного типа. Рассмотрим следующий код для объявления переменной типа int:

int x;
x = 10;

В этом примере переменная x имеет тип int и Java инициализирует её как 0. Когда вы присвоите переменной значение 10 (вторая строка), это значение сохранится в ячейке памяти, на которую ссылается x.

Но когда вы объявляете ссылочный тип, процесс выглядит иначе. Посмотрим на следующий код:

Integer num;
num = new Integer(10);

В первой строке объявлена переменная num, ее тип не относится к встроенному, следовательно, значением является ссылка (тип этой переменной, Integer, является ссылочным типом). Поскольку вы еще не указали, на что собираетесь ссылаться, Java присвоит переменной значение Null, подразумевая «Я ни на что не ссылаюсь».

Во второй строке, ключевое слово new используется для создания объекта типа Integer. Этот объект имеет адрес в памяти, который присваивается переменной num. Теперь, с помощью переменной num вы можете обратиться к объекту используя оператора разыменования ..

Исключение, о котором вы говорите в вопросе, возникает, если вы объявили переменную, но не создали объект, то есть если вы попытаетесь разыменовать num до того, как создали объект, вы получите NullPointerException. В самом простом случае, компилятор обнаружит проблему и сообщит, что

num may not have been initialized

Что говорит: «возможно, переменная num не инициализирована».

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

public void doSomething(Integer num){
   // Работаем с num
}

В этом случае создание объекта (переменная num) лежит на вызывающем коде, то есть вы предполагаете, что он был создан ранее – до вызова метода doSomething. К сожалению, следующий вызов метода вполне возможен:

doSomething(null);

В этом случае значение переменной num будет null. Лучшим способом избежать данного исключения будет проверка на равенство нулю. Как результат, функция doSomething должна быть переписана следующим образом:

public void doSomething(Integer num){
    if (num != null) {
       // Работаем с num
    }
}

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

public void doSomething(Integer num){
    if (num == null)
        throw new IllegalArgumentException("Num не должен быть null"); 
    // Работаем с num
}

Также, обратите внимание на вопрос «Что такое stack trace и как с его помощью находить ошибки при разработке приложений?».

_{Перевод ответа «What is a Null Pointer Exception, and how do I fix it?» @Vincent Ramdhanie.}

В этом посте я покажу наглядный пример того, как исправить ошибку исключения Null Pointer (java.lang.nullpointerexception). В Java особое значение null может быть назначено для ссылки на объект и означает, что объект в данный момент указывает неизвестную область данных.

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

Это исключение возникает следующих случаях:

• Вызов метода из объекта значения null.
• Доступ или изменение объекта поля null.
• Принимает длину null(если бы это был массив Java).
• Доступ или изменение ячеек объекта null.
• Показывает «0», значение Throwable.
• При попытке синхронизации по нулевому объекту.

NullPointerException является RuntimeException, и, таким образом, компилятор Javac не заставляет вас использовать блок try-catch для соответствующей обработки.

Зачем нам нужно значение null?

Как уже упоминалось, null – это специальное значение, используемое в Java. Это чрезвычайно полезно при кодировании некоторых шаблонов проектирования, таких как Null Object pattern и шаблон Singleton pattern.

Шаблон Singleton обеспечивает создание только одного экземпляра класса, а также направлен на предоставление глобального доступа к объекту.

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

import java.util.UUID;

class Singleton {

     private static Singleton single = null;
     private String ID = null;

     private Singleton() {
          /* Make it private, in order to prevent the creation of new instances of
           * the Singleton class. */

          ID = UUID.randomUUID().toString(); // Create a random ID.
     }

     public static Singleton getInstance() {
          if (single == null)
               single = new Singleton();

          return single;
     }

     public String getID() {
          return this.ID;
     }
}

public class TestSingleton {
     public static void main(String[] args) {
          Singleton s = Singleton.getInstance();
          System.out.println(s.getID());
     }
}

В этом примере мы объявляем статический экземпляр класса Singleton. Этот экземпляр инициализируется не более одного раза внутри метода getInstance.

Обратите внимание на использование нулевого значения, которое разрешает создание уникального экземпляра.

Как избежать исключения Null Pointer

Чтобы решить и избежать исключения NullPointerException, убедитесь, что все ваши объекты инициализированы должным образом, прежде чем использовать их.

Когда вы объявляете ссылочную переменную, вы должны создать указатель на объект и убедиться, что указатель не является нулевым, прежде чем запрашивать метод или поле у ​​объекта.

Кроме того, если выдается исключение, используйте информацию, находящуюся в трассировке стека исключения. Трассировка стека выполнения обеспечивается JVM, чтобы включить отладку. Найдите метод и строку, в которой было обнаружено исключение, а затем выясните, какая ссылка равна нулю в этой конкретной строке.

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

1. Сравнение строк с литералами

Очень распространенный случай, выполнения программы включает сравнение между строковой переменной и литералом. Литерал может быть строкой или элементом Enum.

Вместо того, чтобы вызывать метод из нулевого объекта, рассмотрите возможность вызова его из литерала. Например:

String str = null;
if(str.equals("Test")) {
     /* The code here will not be reached, as an exception will be thrown. */
}

Приведенный выше фрагмент кода вызовет исключение NullPointerException. Однако, если мы вызываем метод из литерала, поток выполнения продолжается нормально:

String str = null;
if("Test".equals(str)) {
     /* Correct use case. No exception will be thrown. */
}

1. Проверка аргументов метода

Перед выполнением вашего собственного метода обязательно проверьте его аргументы на наличие нулевых значений.

В противном случае вы можете вызвать исключение IllegalArgumentException.

Например:

public static int getLength(String s) {
     if (s == null)
          throw new IllegalArgumentException("The argument cannot be null");

     return s.length();
}

1. Предпочтение метода String.valueOf() вместо of toString()

Когда код вашей программы требует строковое представление объекта, избегайте использования метода toString объекта. Если ссылка вашего объекта равна нулю, генерируется исключение NullPointerException.

Вместо этого рассмотрите возможность использования статического метода String.valueOf, который не выдает никаких исключений и «ноль», если аргумент функции равен нулю.

1. Используйте Ternary Operator

Ternary Operator – может быть очень полезным. Оператор имеет вид:

boolean expression ? value1 : value2;

Сначала вычисляется логическое выражение. Если выражение true, то возвращается значение1, в противном случае возвращается значение2. Мы можем использовать Ternary Operator для обработки нулевых указателей следующим образом:

String message = (str == null) ? "" : str.substring(0, 10);

Переменная message будет пустой, если ссылка str равна нулю. В противном случае, если str указывает на фактические данные, в сообщении будут первые 10 символов.

1. создайте методы, которые возвращают пустые коллекции вместо нуля.

Очень хорошая техника – создавать методы, которые возвращают пустую коллекцию вместо нулевого значения. Код вашего приложения может перебирать пустую коллекцию и использовать ее методы и поля. Например:

public class Example {
     private static List<Integer> numbers = null;

     public static List<Integer> getList() {
          if (numbers == null)
               return Collections.emptyList();
          else
               return numbers;
     }
}

1. Воспользуйтесь классом Apache’s StringUtils.

Apache’s Commons Lang – это библиотека, которая предоставляет вспомогательные утилиты для API java.lang, такие как методы манипулирования строками.

Примером класса, который обеспечивает манипулирование String, является StringUtils.java, который спокойно обрабатывает входные строки с нулевым значением.

Вы можете воспользоваться методами: StringUtils.isNotEmpty, StringUtils.IsEmpty и StringUtils.equals, чтобы избежать NullPointerException. Например:

if (StringUtils.isNotEmpty(str)) {
     System.out.println(str.toString());
}

1. Используйте методы: contains(), containsKey(), containsValue()

Если в коде вашего приложения используется Maps, рассмотрите возможность использования методов contains, containsKey и containsValue. Например, получить значение определенного ключа после того, как вы проверили его существование на карте:

Map<String, String> map = …
…
String key = …
String value = map.get(key);
System.out.println(value.toString()); // An exception will be thrown, if the value is null.

System.out.println(value.toString()); // В приведенном выше фрагменте мы не проверяем, существует ли на самом деле ключ внутри карты, и поэтому возвращаемое значение может быть нулевым. Самый безопасный способ следующий:

Map<String, String> map = …
…
String key = …
if(map.containsKey(key)) {
     String value = map.get(key);
     System.out.println(value.toString()); // No exception will be thrown.
}

1. Проверьте возвращаемое значение внешних методов

На практике очень часто используются внешние библиотеки. Эти библиотеки содержат методы, которые возвращают ссылку. Убедитесь, что возвращаемая ссылка не пуста.

1. Используйте Утверждения

Утверждения очень полезны при тестировании вашего кода и могут использоваться, чтобы избежать выполнения фрагментов кода. Утверждения Java реализуются с помощью ключевого слова assert и выдают AssertionError.

Обратите внимание, что вы должны включить флажок подтверждения JVM, выполнив его с аргументом -ea. В противном случае утверждения будут полностью проигнорированы.

Примером использования утверждений Java является такая версия кода:

public static int getLength(String s) {
     /* Ensure that the String is not null. */
     assert (s != null);

     return s.length();
}

Если вы выполните приведенный выше фрагмент кода и передадите пустой аргумент getLength, появится следующее сообщение об ошибке:
Exception in thread "main" java.lang.AssertionError
Также вы можете использовать класс Assert предоставленный средой тестирования jUnit.

1. Модульные тесты

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

Существующие безопасные методы NullPointerException

Доступ к статическим членам или методам класса

Когда ваш вы пытаетесь получить доступ к статической переменной или методу класса, даже если ссылка на объект равна нулю, JVM не выдает исключение.

Это связано с тем, что компилятор Java хранит статические методы и поля в специальном месте во время процедуры компиляции. Статические поля и методы связаны не с объектами, а с именем класса.

class SampleClass {

     public static void printMessage() {
          System.out.println("Hello from Java Code Geeks!");
     }
}

public class TestStatic {
     public static void main(String[] args) {
          SampleClass sc = null;
          sc.printMessage();
     }
}

Несмотря на тот факт, что экземпляр SampleClass равен нулю, метод будет выполнен правильно. Однако, когда речь идет о статических методах или полях, лучше обращаться к ним статическим способом, например, SampleClass.printMessage ().

Оператор instanceof

Оператор instanceof может использоваться, даже если ссылка на объект равна нулю.

Оператор instanceof возвращает false, когда ссылка равна нулю.

String str = null;
if(str instanceof String)
     System.out.println("It's an instance of the String class!");
else
     System.out.println("Not an instance of the String class!");

В результате, как и ожидалось:

Not an instance of the String class!

Смотрите видео, чтобы стало понятнее.

Довольно часто при разработке на Java программисты сталкиваются с NullPointerException, появляющимся в самых неожиданных местах. В этой статье мы разберёмся, как это исправить и как стараться избегать появления NPE в будущем.

NullPointerException (оно же NPE) это исключение, которое выбрасывается каждый раз, когда вы обращаетесь к методу или полю объекта по ссылке, которая равна null. Разберём простой пример:

Integer n1 = null;
System.out.println(n1.toString());

Здесь на первой строке мы объявили переменную типа Integer и присвоили ей значение null (то есть переменная не указывает ни на какой существующий объект).
На второй строке мы обращаемся к методу toString переменной n1. Так как переменная равна null, метод не может выполниться (переменная не указывает ни на какой реальный объект), генерируется исключение NullPointerException:

Exception in thread "main" java.lang.NullPointerException
	at ru.javalessons.errors.NPEExample.main(NPEExample.java:6)

Как исправить NullPointerException

В нашем простейшем примере мы можем исправить NPE, присвоив переменной n1 какой-либо объект (то есть не null):

Integer n1 = 16;
System.out.println(n1.toString());

Теперь не будет исключения при доступе к методу toString и наша программа отработает корректно.

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

Иногда вам требуется использовать отладку и пошагово проходить программу, чтобы определить источник NPE.

Как избегать исключения NullPointerException

Существует множество техник и инструментов для того, чтобы избегать появления NullPointerException. Рассмотрим наиболее популярные из них.

Проверяйте на null все объекты, которые создаются не вами

Если объект создаётся не вами, иногда его стоит проверять на null, чтобы избегать ситуаций с NullPinterException. Здесь главное определить для себя рамки, в которых объект считается «корректным» и ещё «некорректным» (то есть невалидированным).

Не верьте входящим данным

Если вы получаете на вход данные из чужого источника (ответ из какого-то внешнего сервиса, чтение из файла, ввод данных пользователем), не верьте этим данным. Этот принцип применяется более широко, чем просто выявление ошибок NPE, но выявлять NPE на этом этапе можно и нужно. Проверяйте объекты на null. В более широком смысле проверяйте данные на корректность, и консистентность.

Возвращайте существующие объекты, а не null

Если вы создаёте метод, который возвращает коллекцию объектов – не возвращайте null, возвращайте пустую коллекцию. Если вы возвращаете один объект – иногда удобно пользоваться классом Optional (появился в Java 8).

Заключение

В этой статье мы рассказали, как исправлять ситуации с NullPointerException и как эффективно предотвращать такие ситуации при разработке программ.

Эта простая статья скорее для начинающих разработчиков Java, хотя я нередко вижу и опытных коллег, которые беспомощно глядят на stack trace, сообщающий о NullPointerException (сокращённо NPE), и не могут сделать никаких выводов без отладчика. Разумеется, до NPE своё приложение лучше не доводить: вам помогут null-аннотации, валидация входных параметров и другие способы. Но когда пациент уже болен, надо его лечить, а не капать на мозги, что он ходил зимой без шапки.

Итак, вы узнали, что ваше приложение упало с NPE, и у вас есть только stack trace. Возможно, вам прислал его клиент, или вы сами увидели его в логах. Давайте посмотрим, какие выводы из него можно сделать.

NPE может произойти в трёх случаях:

1. Его кинули с помощью throw
2. Кто-то кинул null с помощью throw
3. Кто-то пытается обратиться по null-ссылке

Во втором и третьем случае message в объекте исключения всегда null, в первом может быть произвольным. К примеру, java.lang.System.setProperty кидает NPE с сообщением «key can’t be null», если вы передали в качестве key null. Если вы каждый входной параметр своих методов проверяете таким же образом и кидаете исключение с понятным сообщением, то вам остаток этой статьи не потребуется.

Обращение по null-ссылке может произойти в следующих случаях:

1. Вызов нестатического метода класса
2. Обращение (чтение или запись) к нестатическому полю
3. Обращение (чтение или запись) к элементу массива
4. Чтение length у массива
5. Неявный вызов метода valueOf при анбоксинге (unboxing)

Важно понимать, что эти случаи должны произойти именно в той строчке, на которой заканчивается stack trace, а не где-либо ещё.

Рассмотрим такой код:

 1: class Data {
 2:    private String val;
 3:    public Data(String val) {this.val = val;}
 4:    public String getValue() {return val;}
 5: }
 6:
 7: class Formatter {
 8:    public static String format(String value) {
 9:        return value.trim();
10:    }
11: }
12:
13: public class TestNPE {
14:    public static String handle(Formatter f, Data d) {
15:        return f.format(d.getValue());
16:    }
17: }

Откуда-то был вызван метод handle с какими-то параметрами, и вы получили:

Exception in thread "main" java.lang.NullPointerException
    at TestNPE.handle(TestNPE.java:15)

В чём причина исключения — в f, d или d.val? Нетрудно заметить, что f в этой строке вообще не читается, так как метод format статический. Конечно, обращаться к статическому методу через экземпляр класса плохо, но такой код встречается (мог, например, появиться после рефакторинга). Так или иначе значение f не может быть причиной исключения. Если бы d был не null, а d.val — null, тогда бы исключение возникло уже внутри метода format (в девятой строчке). Аналогично проблема не могла быть внутри метода getValue, даже если бы он был сложнее. Раз исключение в пятнадцатой строчке, остаётся одна возможная причина: null в параметре d.

Вот другой пример:

 1: class Formatter {
 2:     public String format(String value) {
 3:         return "["+value+"]";
 4:     }
 5: }
 6: 
 7: public class TestNPE {
 8:     public static String handle(Formatter f, String s) {
 9:         if(s.isEmpty()) {
10:             return "(none)";
11:         }
12:         return f.format(s.trim());
13:     }
14: }

Снова вызываем метод handle и получаем

Exception in thread "main" java.lang.NullPointerException
	at TestNPE.handle(TestNPE.java:12)

Теперь метод format нестатический, и f вполне может быть источником ошибки. Зато s не может быть ни под каким соусом: в девятой строке уже было обращение к s. Если бы s было null, исключение бы случилось в девятой строке. Просмотр логики кода перед исключением довольно часто помогает отбросить некоторые варианты.

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

if("".equals(s))

Теперь в самой строчке обращения к полям и методам s нету, а метод equals корректно обрабатывает null, возвращая false, поэтому в таком случае ошибку в двенадцатой строке мог вызвать как f, так и s. Анализируя вышестоящий код, уточняйте в документации или исходниках, как используемые методы и конструкции реагируют на null. Оператор конкатенации строк +, к примеру, никогда не вызывает NPE.

Вот такой код (здесь может играть роль версия Java, я использую Oracle JDK 1.7.0.45):

 1: import java.io.PrintWriter;
 2: 
 3: public class TestNPE {
 4:     public static void dump(PrintWriter pw, MyObject obj) {
 5:         pw.print(obj);
 6:     }
 7: }

Вызываем метод dump, получаем такое исключение:

Exception in thread "main" java.lang.NullPointerException
	at java.io.PrintWriter.write(PrintWriter.java:473)
	at java.io.PrintWriter.print(PrintWriter.java:617)
	at TestNPE.dump(TestNPE.java:5)

В параметре pw не может быть null, иначе нам не удалось бы войти в метод print. Возможно, null в obj? Легко проверить, что pw.print(null) выводит строку «null» без всяких исключений. Пойдём с конца. Исключение случилось здесь:

472: public void write(String s) {
473:     write(s, 0, s.length());
474: }

В строке 473 возможна только одна причина NPE: обращение к методу length строки s. Значит, s содержит null. Как так могло получиться? Поднимемся по стеку выше:

616: public void print(Object obj) {
617:     write(String.valueOf(obj));
618: }

В метод write передаётся результат вызова метода String.valueOf. В каком случае он может вернуть null?

public static String valueOf(Object obj) {
   return (obj == null) ? "null" : obj.toString();
}

Единственный возможный вариант — obj не null, но obj.toString() вернул null. Значит, ошибку надо искать в переопределённом методе toString() нашего объекта MyObject. Заметьте, в stack trace MyObject вообще не фигурировал, но проблема именно там. Такой несложный анализ может сэкономить кучу времени на попытки воспроизвести ситуацию в отладчике.

Не стоит забывать и про коварный автобоксинг. Пусть у нас такой код:

 1: public class TestNPE {
 2:     public static int getCount(MyContainer obj) {
 3:         return obj.getCount();
 4:     }
 5: }

И такое исключение:

Exception in thread "main" java.lang.NullPointerException
	at TestNPE.getCount(TestNPE.java:3)

На первый взгляд единственный вариант — это null в параметре obj. Но следует взглянуть на класс MyContainer:

import java.util.List;

public class MyContainer {
    List<String> elements;
    
    public MyContainer(List<String> elements) {
        this.elements = elements;
    }
    
    public Integer getCount() {
        return elements == null ? null : elements.size();
    }
}

Мы видим, что getCount() возвращает Integer, который автоматически превращается в int именно в третьей строке TestNPE.java, а значит, если getCount() вернул null, произойдёт именно такое исключение, которое мы видим. Обнаружив класс, подобный классу MyContainer, посмотрите в истории системы контроля версий, кто его автор, и насыпьте ему крошек под одеяло.

Помните, что если метод принимает параметр int, а вы передаёте Integer null, то анбоксинг случится до вызова метода, поэтому NPE будет указывать на строку с вызовом.

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

Сбои — головная боль для всех вовлеченных. Команды разработки ненавидят разбираться с ними, а пользователи не желают мириться — 62% пользователей удаляют приложение в случае сбоев, говорит исследование DCI. Нестабильность приложения может быстро привести к провалу всего проекта или, по крайней мере, дорого обойтись. Чтобы свести к минимуму сбои приложения и время, необходимое для их устранения, мы собрали наиболее распространенные ошибки Android-приложений и способы их устранения.

5 самых распространенных ошибок в Android-приложениях и способы их устранения

java.lang.NullPointerException

Определенно, самый частый креш в Android. Скорее всего, если вы когда-либо разрабатывали приложение для Android, то сталкивались с этой ошибкой. Наиболее частой причиной NullPointerException является ссылка на данные после выхода за пределы области видимости или сборки мусора.

Обычно это происходит, когда приложение переходит в фоновый режим, и избавляется от ненужной памяти. Это приводит к потере некоторых ссылок, и когда метод Android onResume () вызывается снова, это может привести к ошибке NullPointException.

Чтобы точно определить, где произошла ошибка, используйте трассировку стека. И, чтобы избежать ошибки и потери данных, вы должны стремиться сохранить свои данные в более надежном месте, когда вызывается метод onPause(). Просто вытащите их обратно при вызове onResume(). И, в общем, старайтесь обрабатывать любые потенциальные нулевые указатели, которые могут вызвать ошибку.

java.lang.IllegalStateException

Одна из наиболее распространенных ошибок Android-приложений, имеющих дело с Фрагментами. Ошибка IllegalStateException может происходить по множеству причин, но в основе ее лежит неправильное управление состояниями Activity.

Она возникает, когда в фоновом потоке выполняется трудоемкая операция, но тем временем создается новый Фрагмент, который отсоединяется от Activity до завершения фонового потока. Это приводит к вызову отсоединенного фрагмента и появлению такого исключения.

Чтобы решить эту проблему, вы должны отменить фоновый поток при приостановке или остановке Фрагмента. Кроме того, вы можете использовать метод isAdded(), чтобы проверить, прикреплен ли Фрагмент, а затем использовать getResources() из Activity.

java.lang.IndexOutOfBoundsException

IndexOutOfBoundsException — одно из самых распространенных исключений RunTimeExceptions, с которыми вы можете столкнуться. Эта ошибка указывает на то, что какой-либо индекс (обычно в массиве, но может быть и в строке или векторе) находится вне допустимого диапазона.

Есть несколько распространенных причин возникновения этого сбоя — использование отрицательного индекса с массивами, charAt или функцией substring. Также, если beginIndex меньше 0 или endIndex больше длины входной строки, или beginIndex больше endIndex. Другая причина — когда endIndex — beginIndex меньше 0. Но, вероятно, наиболее распространенная причина — когда входной массив (строка/вектор) пуст.

Исправить эту проблему относительно просто, всегда лучше проверять трассировку стека всякий раз, когда возникает ошибка. Первым ключевым шагом является понимание того, что вызвало сбой. После этого нужно убедиться, что этот массив, строка или вектор соответствуют требуемому индексу.

java.lang.IllegalArgumentException

Вероятно, наиболее общая причина сбоя в списке — исключение IllegalArgumentException. Самое простое его определение заключается в том, что ваш аргумент неправильный. Этому может быть много причин. Однако есть несколько общих правил.

Одна из наиболее частых причин — попытка получить доступ к элементам пользовательского интерфейса непосредственно из фонового потока. Также, если вы пытаетесь использовать переработанное растровое изображение. Другая распространенная причина — вы забыли добавить Activity в Manifest. Это не будет показано компилятором, так как это RuntimeException.

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

java.lang.OutOfMemoryError

И последний, но не менее важный в нашем списке — один из самых неприятных крешей. Устройства Android бывают всех форм и с разным объемом памяти. Часто бывает, что вы имеете дело с ограниченными ресурсами. OutOfMemoryError возникает, когда ОС необходимо освободить память для высокоприоритетных операций, и она берется из выделенной вашему приложению кучи. Управление памятью становится проще, поскольку новые устройства имеют гораздо больше памяти. Однако не все пользователи вашего приложения будут работать с ними.

Что касается самой ошибки, то одна из основных причин утечки памяти, приводящей к OutOfMemoryError, — это слишком долгое сохранение ссылки на объект. Это может привести к тому, что ваше приложение будет использовать намного больше памяти, чем необходимо. Одна из наиболее распространенных причин — растровые изображения, которые в настоящее время могут быть большого размера. Поэтому не забудьте утилизировать любой объект, который возможно, когда он больше не нужен.

Вы можете запросить у ОС больше памяти для кучи, добавив в свой файл манифеста атрибут

android:largeHeap="true"

Однако это не рекомендуется, кроме случаев крайней необходимости, поскольку это всего лишь запрос и он может быть отклонен.

Источник

Если вы нашли опечатку — выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.