Android studio unchecked cast

Предупреждение Java “Непроверенное приведение”

Автор: Kai Yuan
Дата записи

1. Обзор

Иногда, когда мы компилируем наши исходные файлы Java, мы видим предупреждающие сообщения ” непроверенное приведение “, напечатанные компилятором Java.

В этом уроке мы подробнее рассмотрим предупреждающее сообщение. Мы обсудим, что означает это предупреждение, почему нас предупреждают и как решить проблему.

Некоторые компиляторы Java по умолчанию подавляют непроверенные предупреждения.

Давайте убедимся, что мы включили опцию компилятора для печати “непроверенных” предупреждений , прежде чем мы рассмотрим это ” непроверенное приведение ” предупреждение.

2. Что означает предупреждение “непроверенный бросок”?

“ Непроверенное приведение ” является предупреждением во время компиляции . Проще говоря, мы увидим это предупреждение при приведении необработанного типа к параметризованному типу без проверки типа .

Пример может объяснить это прямолинейно. Допустим, у нас есть простой метод возврата необработанного типа Map :

Теперь давайте создадим тестовый метод для вызова метода, описанного выше, и приведем результат к Map LocalDate> : LocalDate>

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

Но если мы скомпилируем наши исходные тексты Java, компилятор выведет предупреждающее сообщение. Далее давайте скомпилируем и запустим наши модульные тесты с помощью Maven:

Как показывает вывод Maven, мы успешно воспроизвели предупреждение.

С другой стороны, наш тест работает без каких-либо проблем, даже если мы видим предупреждение компилятора ” непроверенное приведение “.

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

3. Почему компилятор Java Предупреждает Нас?

Наш метод тестирования отлично работает в предыдущем разделе, хотя мы видим предупреждение ” непроверенное приведение “. Это связано с тем, что когда мы приводили необработанный тип Map в Map , LocalDate> , необработанная Карта содержит только LocalDate> записи. То есть, типизация безопасна. , LocalDate>

Чтобы проанализировать потенциальную проблему, давайте немного изменим метод getrowmap () , добавив еще одну запись в необработанный тип Карта :

На этот раз мы добавили новую запись в Карту с типом в методе выше.

Теперь давайте напишем новый метод тестирования для вызова метода get Raw Map Со смешанными типами() :

Если мы скомпилируем и запустим тест, снова будет напечатано предупреждающее сообщение ” непроверенное приведение “. Кроме того, наш тест пройдет.

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

Если мы рассмотрим это поближе, исключение ClassCastException не возникает в строке приведения необработанного типа Map к Map , хотя предупреждающее сообщение указывает на эту строку. Вместо этого исключение возникает, когда мы получаем данные с неправильным типом с помощью ключа : , приведенного из необработанной карты.get(“дата 4”).

Если мы приведем необработанную коллекцию типов, содержащую данные с неправильными типами, к коллекции параметризованных типов, исключение ClassCastException не будет создано, пока мы не загрузим данные с неправильным типом .

Иногда мы можем получить исключение слишком поздно.

Например, мы получаем необработанный тип Map со многими записями, вызывая наш метод, а затем приводим его к Map с параметризованным типом:

Для каждой записи в Карте нам нужно отправить Локальные данные объекта в удаленный API. До тех пор , пока мы не столкнемся с ClassCastException , весьма вероятно, что уже было сделано много вызовов API. В зависимости от требований могут потребоваться некоторые дополнительные процессы восстановления или очистки данных.

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

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

4. Что Мы Должны Делать С Предупреждением?

4.1. Избегайте Использования Необработанных Типов

Дженерики были введены с Java 5. Если наша среда Java поддерживает универсальные типы, нам следует избегать использования необработанных типов. Это связано с тем, что использование необработанных типов приведет к тому, что мы потеряем все преимущества дженериков в плане безопасности и выразительности.

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

Однако иногда нам приходится работать с некоторыми старыми библиотеками. Методы из этих старых внешних библиотек могут возвращать необработанные коллекции типов.

Вызов этих методов и приведение к параметризованным типам приведет к появлению предупреждения компилятора ” непроверенное приведение “. Но у нас нет контроля над внешней библиотекой.

Далее давайте посмотрим, как вести это дело.

4.2. Подавите предупреждение “непроверено” .

Если мы не можем устранить предупреждение ” непроверенное приведение “, и мы уверены, что код, вызывающий предупреждение, является типобезопасным, мы можем подавить предупреждение , используя аннотацию SuppressWarnings(“непроверенный”) .

Когда мы используем @ Предупреждения о подавлении(“непроверено”) аннотация, мы всегда должны помещать ее в минимально возможную область.

Давайте рассмотрим метод remove() из класса ArrayList в качестве примера:

4.3. Проверка Сохранности Типов Перед Использованием Коллекции Необработанных Типов

Как мы узнали, @Suppresswarnings(“непроверено”) аннотация просто подавляет предупреждающее сообщение, фактически не проверяя, является ли приведение типобезопасным.

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

5. Заключение

В этой статье мы узнали, что означает предупреждение компилятора ” непроверенное приведение “.

Кроме того, мы рассмотрели причину этого предупреждения и способы решения потенциальной проблемы.

Как всегда, весь код в этой записи доступен на GitHub .

Источник

Как решить предупреждение Unchecked cast android studio?

У меня есть предупреждение:

Я видел этот вопрос и этот , но мне не удалось решить свою проблему. Я должен получить данные к bundle по фрагментам. Может быть, у кого-то была похожая проблема и он знает, как ее решить?

UPDATE

У меня есть эта глобальная переменная:

как я получаю его из-за комментариев и ответов:

и у меня есть эта as HashMap часть желтая и предупреждающая:

2 ответа

В моем проекте Android я сделал абстрактный класс AsyncTask, в котором я ввожу URL и, если это необходимо, информацию о подкачке, так что мне не нужно продолжать писать материал HTTP и т. д. Я сделал абстрактный метод onAsyncTaskResult (Object o), который должен быть реализован при использовании.

Я сталкиваюсь с предупреждениями о неконтролируемом броске. Я не знаю, как разрешить эти предупреждения. Ошибка компилятора, похоже, выбирает list = (E[]) new IntKeyed [size]; Это код, который мы должны использовать буква за буквой. Мы пытаемся использовать дженерики, отсюда и E. Поэтому я решил.

Вы можете использовать безопасное приведение , чтобы получить необязательное значение из вашего bundle, например

Таким образом, ваш filterData будет иметь тип HashMap ? . В случае неудачи приведения filterData будет null, и вам придется справиться с этим делом.

Попробуйте применить решение @Vladyslav Матвиенко следующим образом.

Похожие вопросы:

Я добавил объекты в ArrayList ArrayList

parking=new ArrayList<>(); и записал весь список как объект в файл. void exportArrayListy() throws IOException< FileOutputStream fo=new.

Map one = (Map ) parent.getAdapter().getItem(position); Type safety: Unchecked cast from Object to Map с приведенной выше строкой кода я получаю это.

Я получаю предупреждение type safety: Unchecked cast from Object to ArrayList в строке с readObject() в этом фрагменте кода: // Read the Event List theEventArrayList = new.

В моем проекте Android я сделал абстрактный класс AsyncTask, в котором я ввожу URL и, если это необходимо, информацию о подкачке, так что мне не нужно продолжать писать материал HTTP и т. д. Я.

Я сталкиваюсь с предупреждениями о неконтролируемом броске. Я не знаю, как разрешить эти предупреждения. Ошибка компилятора, похоже, выбирает list = (E[]) new IntKeyed [size]; Это код, который мы.

Я написал метод получения представлений по идентификатору в Android следующим образом: E.g. Button button = find(R.id.someId); На самом деле нет никакой необходимости в кнопке <>.

Я создаю свой собственный класс set . Но в самом начале я принимаю предупреждение. Я использую в этой ссылке Как создать универсальный массив? . Но я уже принял предупреждение. Это мое.

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

Я пытаюсь реализовать DoublyLinkedList с помощью genenerics. Согласно документам Java , аргумент метода remove() должен быть объектом. Если я попытаюсь привести объект o к данным T, я получу.

Я создал метод, который делает несколько вызовов с retrofit и возвращает список продуктов с помощью оператора combineLatest rxjava, а затем использую функцию map, чтобы получить только.

Источник

Что такое unchecked cast и как его проверить?

Я думаю, что понимаю, что означает непроверенный бросок (бросание от одного к другому другого типа), но что значит «проверить» бросок? Как я могу проверить приведение, чтобы избежать этого предупреждения в Eclipse?

3 ответов

Unchecked cast означает, что вы (неявно или явно) переходите от универсального типа к неквалифицированному типу или наоборот. Е. Г. эта строка

произведет такое предупреждение.

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

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

если вы не можете устранить предупреждение, и вы можете доказать, что код, который спровоцированное предупреждение является typesafe, а затем (и только тогда) подавляет предупреждение с @SuppressWarnings(«unchecked») Примечание. Если вы подавляете предупреждения без предварительного доказательства, что код typesafe, вы только даете себе ложное чувство безопасности. Код может компилироваться без каких-либо предупреждений, но он все еще может бросить ClassCastException во время выполнения. Если, однако, вы игнорируете непроверенные предупреждения, которые, как вы знаете, безопасны (вместо их подавления), вы не заметит, когда появится новое предупреждение, которое представляет реальную проблему. Этот новое предупреждение потеряется среди всех ложных тревог, которые вы не молчали.

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

чтобы ellaborate больше о том, что Петр написал:

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

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

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

вот пример, основанный на Consider typesafe heterogenous containers раздел 3-го изд. «эффективной Java» Джошуа Блоха, но класс контейнера намеренно сломан — он хранит и возвращает неправильный тип:

Если retrieve() использует снят литой — (T)map.get(key) запуск этой программы приведет к ClassCastException произошедшим в Integer i = ints.get(0) линии. The retrieve() метод будет завершен, потому что фактический тип не был проверен во время выполнения:

Но если retrieve() использует проверено cast — key.cast(map.get(key)) запуск этой программы приведет к ClassCastException произошедшим в key.cast(map.get(key)) line, потому что проверенное приведение обнаружит, что тип неверен, и выдаст исключение. The retrieve() метод не будет полным:

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

чтобы избежать непроверенных бросает предупреждение, @SuppressWarnings(«unchecked») можно использовать, если программист действительно уверен, что метод на самом деле безопасный. Лучшей альтернативой является использование дженериков и проверенных слепков, когда это возможно.

как выразился Джошуа блох,

. непроверенные предупреждения важны. Не игнорируйте их.

для полноты, этой ответ касается особенностей Eclipse.

Источник

Unchecked cast

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

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

работает как надо.

В связи с этим я постоянно перебрасываю массив между типом массива и типом листа.
В одну сторону работает всегда: Arrays.asList(array)
В другую получается, если наперед известен тип: list.toArray(new KnownType[list.size()])
А при неизвестном типе есть проблемы:

warning: [unchecked] unchecked call to push(E) as a member of the raw type Stack
Написал прогу она «компилируется» и работает. Но смущает то что в консоль при «компиляции» выбивает.

Checked и unchecked исключения
Правильно ли я понимаю, что в классе Throwable и в его потомках нет никакого признака, который.

Unchecked generic array creation for varargs parameter
Сегодня случайно увидел, что среда разработки обращает внимание на вызов метода с вот такой.

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

И это неудивительно. Вы создаете массив во время исполнения, а тип при этом уже неизвестен, ввиду такого явления как type erasure. Тип Т известен только при компиляции.

В общем, используйте ArrayList с типом. И проблем будет сильно меньше.

Значит всё-таки, нужно с листами работать.

Правда, поправлю Вас, Вы не правильно поняли причину проблемы.

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

1. Если Вы работали с массивами и Вас это устраивало — значит, расширения массива алгоритм не требовал. Т.е. накладные расходы на это можно опустить. В любом случае исходным размером массива можно управлять.

2. А зачем Вам возвращать именно массив? Если это надо делать очень часто — значит, ArrayList Вам не подходит по алгоритму.

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

Class cast при получении элемента из списка
Читаю про Generics и возник вопрос. Почему компилятор не пропускает следующее присвоение: .

Отличие uncaught exception и unchecked exception в Java
Добрый день! У меня возник вопрос: в чём отличие uncaught exception и unchecked exception в.

.java uses unchecked or unsafe operations
при выполнении команды «очистить и собрать» выдает эту ошибку в выводах Note.

Сообщение при компиляции под Java 1.5: Some input files use unchecked or unsafe operations
Удосужился, наконец, перейти на Java 1.5. Компилирую старый проект и вылазит такая бяка: Some.

Источник