Как предотвратить сбой из-за java.util.Date.toString?
Иногда следующий код вызывает сбой приложения Android:
try {
(new Date()).toString());
} catch (Exception ex) {
...
}
Трассировки стека:
java.lang.AssertionError:
at android.icu.impl.TimeZoneNamesImpl$ZNames.getNameTypeIndex (TimeZoneNamesImpl.java:724)
at android.icu.impl.TimeZoneNamesImpl$ZNames.getName (TimeZoneNamesImpl.java:790)
at android.icu.impl.TimeZoneNamesImpl.getTimeZoneDisplayName (TimeZoneNamesImpl.java:183)
at android.icu.text.TimeZoneNames.getDisplayName (TimeZoneNames.java:261)
at java.util.TimeZone.getDisplayName (TimeZone.java:405)
at java.util.Date.toString (Date.java:1066)
Судя по всему, ошибку не отловить. Есть ли способ предотвратить это?
Для отладки вы можете попробовать сохранить new Date() в переменной и получить доступ к различным полям.
AssertionError расширяет Error, а не Exception. Вы можете поймать это, если явно поймаете AssertionErrorсвязанные github.com/google/volley/issues/177
@crgarridos targetSdkVersion 27
Ответы 2
Очень странная проблема ...
Кстати, это не исключение, а AssertionError, который расширяется от Error.
Вы можете поймать это, используя:
try {
(new Date()).toString());
} catch (AssertionError ex) {// or Error or Throwable
...
}
Если вы получаете AssertionError с использованием новая дата (), что кажется странным и, возможно, связано с проблемой Android 8, а не с вашим кодом, вы можете использовать java.time из Java 8 вместо java.util.Date следующим образом:
import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
DateTimeFormatter formatter = DateTimeFormatter
.ofPattern("yyyy/MM/dd HH:mm:ss")
.withZone(ZoneId.systemDefault()); //you must add time zone because of Instant
Instant currentTimestamp = Instant.now();
System.out.print(formatter.format(currentTimestamp));
Большое спасибо за ваш ответ. Да, это происходит только с устройствами Android 8.1. Я предполагаю, что ваш ответ сработает, но, к сожалению, я не могу принять два ответа.
@Hong Я верю, что вы можете изменить свое согласие, если захотите.
Я знаю, что могу изменить ответ, но не могу принять два ответа одновременно, если правильно понимаю. Я предполагаю, что первый ответ также помогает предотвратить сбой.
Правильное направление в этом ответе с использованием java.time, но LocalDateTime - это как раз тот класс, который здесь не подходит. Отсутствие какой-либо концепции часового пояса или смещения от UTC, LocalDateTime представляет ли нет момент. Вместо этого используйте Instant для UTC или ZonedDateTime для определенного часового пояса.
@Basil Bourque хорошо, круто, спасибо за заметку! Я предполагаю, что вы проголосовали против, и это нормально, хотя я бы улучшил свой ответ только из вашего комментария, но я обновил свой пост, используя Мгновенное, поэтому я не уверен, почему голосование против остается, если оно был ты. В любом случае, каждый предоставленный мной фрагмент предлагает рабочее альтернативное решение исходной проблемы OP.
@ViaTech Мое отрицательное голосование остается, потому что в этом Ответе по-прежнему рекомендуется неправильный класс. Не верьте мне на слово. Просто прочтите документация класса: не может представлять мгновение на временной шкале. Я бы также проголосовал против ответа, в котором каким-то образом удалось суммировать ( 2 + 2 ) с использованием строк или битового массива, а не с использованием int, Integer или BigInteger. Очевидно верный результат не оправдывает ненадлежащее злоупотребление неправильными классами.
@Basil Bourque: Хорошо, твердая ссылка. Я удалил свои примеры, в которых используется LocalDateTime. Однако технически на основе вопроса OPs нет обозначения даты, и в представленной вами документации говорится, что это приемлемо для дней рождения, кто знает, может быть, это помогло бы кому-то.
Можете ли вы указать, на какую версию Android вы нацеливаетесь?