Java lang ошибка в телефоне
Перед устранением убедитесь в отсутствии следующих причин:
- технические работы на сервере;
- окончание возможности пользоваться платными услугами;
- отсутствие подключения интернета от провайдера на компьютере в целом;
- блокировка игрока по IP.
Если перечисленных проблем не замечено, обратите внимание на такие факторы:
- Актуальность версии игры. Если подключиться к серверу невозможно, проверьте наличие обновлений Minecraft. Конфликт файлов неизбежно приведет к ошибке. Достаточно доступа к интернету и возможности загрузки новых пакетов.
- Желание установить новые моды и патчи приводит к тому, что необкатанное ПО блокирует подключение к серверу. Удалите последние дополнения или переустановите игру. Чтобы предотвратить ошибку, используйте проверенные расширения.
- Блокировка брандмауэра или антивируса заслуживает отдельного внимания. Явно определить источник проблемы не получится. Пользователю придется отключать программы для защиты компьютера по очереди.
Если вышеуказанные параметры в порядке, то проще обратиться к администрации сервера.
Ошибка Java.lang.NullPointerException
Ошибка lang.NullPointerException в модуле Java говорит о том, что произошел сбой в работе программы, взаимодействующей с Джавой. Часто проблема возникает у игроков Minecraft.
Если пользователь встретил данную ошибку на стадии запуска игры, переустановите Java на компьютере. Игра, не включающаяся по требованию, также требует переустановки.
Если это не помогло и ошибка с текстом Java.lang.NullPointerException появляется снова, проблемное место находится в самой программе. Правильнее всего написать разработчикам или на специализированный форум.
Пользователям Minecraft также придется создать новую учетную запись на компьютере, наделив ее правами администратора.
Ошибка Java Virtual Machine Launcher
Установка Джавы может сопровождаться ошибкой Java Virtual Machine Launcher. Окно с таким текстом говорит о том, что пользователь некорректно завершил работу с программой или игрой, например, сервером Minecraft. Теперь виртуальной машине не хватает памяти, чтобы загрузиться.
Выделенных дополнительно 512 Мб достаточно, если произошла ошибка при запуске виртуальной Java-машины.
Ошибка Application Blocked by Java Security
Следствием ошибки стало увеличение безопасности в функционале Джава. Программа блокирует доступ пользователя к самоподписанным и неподписанным приложениям. Работает модуль в качестве антивируса с версии 7 Update 51. Проверьте версию Java, обратившись к нашим инструкциям.
Возникает такая проблема и после неудачного обновления ПО от провайдеров или других онлайн-приложений.
Таким образом можно исправлять любые проблемы, связанные с неподписанными или самоподписанными платформами, если к ним есть доверие.
Ошибка A Java Exception has occurred
Выполните поочередно следующие действия:
- Переустановите JVM и JRE.
- Скачайте последнюю версию Minecraft.
- Проверьте драйвера видеокарты.
Если проблема решена после первого этапа, то этого достаточно.
Java не является внутренней или внешней командой
- Определите место установки модуля. Искать можно как JRE, так и JDK (с предустановленным Javac). На Windows 7 и 10 папка Джава расположена по пути C:\Program Files.
- Найдите папку Bin, скопируйте путь до нее целиком. Он может оставаться в буфере обмена, пока выполняются следующие пункты.
- Перейдите в переменные среды (способ описан выше).
- В списке «Системных переменных» есть пункт Path. Сделайте по нему одиночный клик, нажмите «Изменить».
- Рекомендуется сохранить исходную строку, но не стоит забывать, что в буфере обмена находится путь до папки Bin.
- В самый конец строки добавляется путь из буфера. Предварительно поставьте точку с запятой.
- Чтобы сохранить свежую версию переменной, выйдите из настройки и нажмите OK.
Видео: Исправление ошибки «Java не является внутренней или внешней командой» на Windows 7.
Прекращена работа программы Java(TM) Platform SE binary
Если не работает Minecraft или другая программа, пользователь может видеть ошибку «Прекращена работа программы Java(TM) Platform SE binary».
Выявим ее источник:
- Появление ошибки после первого запуска приложения свидетельствует о возможном отсутствии модуля Джава на ПК. Даже если есть какие-то следы ПО, то их лучше удалить и скачать плагин заново.
- Если Джава установлена на компьютере, сравните ее разрядность с аналогичным параметром операционной системы. Для этого найдите плагин в панели управления. Название, не содержащее цифр, говорит о версии x64, в противном случае установлена x32.
После исключения отсутствия модуля или несовместимости остается только один источник проблемы – видеокарта. Выполните следующие действия:
- Создайте новую переменную среды. О том, как это сделать, рассказано выше. Напишите следующие параметры: имя – _JAVA_OPTIONS, значение – -Xmx256M.
- Сохраните переменную, перейдите к настройкам в игре.
- Отключите следующие параметры: VSync, VBos, Smooth Lighting.
- FOV должно иметь значение Normal.
Для закрепления результата обновите драйвера для видеокарты и перезагрузите компьютер.
Ошибка при запуске игры на телефоне
Почему-то выдаёт при большинстве игр которые я закачиваю ошибку такого вида:
Error
java/lang/Error Static initializer: java/lang/RuntimeException: RMS ERROR: Error while initializing reserved MIDLet RMS storage.
Телефон Nokia 5300.
Надеюсь что кто-то с этим встречался и скажет что делать
Siava, спасибо
Жаль, а такие игры не идут прекрасные
Можно закрывать тему тогда.
Painkiller, попробуй вырубить (если присутствует) режим ожидания, да почистить память телефона.
Танцы с бубном, конечно, но отключения режима ожидания реально помогает (правда, при случае с нехваткой оперативной памяти телефона (out of memory))
BossTeR, ожидания?
Как бы это где? в режимах? у меня такого вроде нету, у меня стоит обычный
Painkiller,Это не там.
Настройки/дисплей/активный реж. ож.
Выглядит эта фигня так:
если у тебя такого на дисплее нет-не бери тогда в голову.
BossTeR, понял про что ты неа, ещё с самого начала его убрал.
Добавлено спустя 45 секунд:
Мне ещё говорили что оперативку как-то чистить надо, я темы много раз менял
Painkiller, попробуй юзать PC suit для этого) 5300 с ним дружит)
Или прошей, что будет даже лучше, а если не поможет-точно не помешает. (Слова пугаться не надо, это легально, просто и безболезненно ) Вполне может помочь, я свой, когда дефолтное ПО сменил на последнее-не узнал Делается это через тот же Nokia PC suit (есть у Сявы на ftp) Следуй всем инструкциям, что там дадут-и телефон свой не узнаешь) (на всякий случай, не забудь зарядить перед прошивкой и сделать резервное копирование)
BossTeR, Я уже как-то обновлял пришлось в ремонт после него нести
установлю пс сьют, попробую через неё передать
Painkiller, да ладно? О_О У меня только сколько телефонов уже через Nokia Software Update прошли-только один владелец недоволен был тем, что слетела тема, а какая точно стояла-он не помнил и рыться искать было лень
Там специальная опция есть-установка приложений (а то вдруг просто через Phone Browser зальешь )
Добавлено спустя 27 секунд:
Пришёл домой, скачал на комп и передал по USB и нифига не работает.
обновляет/прошивает? там ещё тип нельзя кабель от телефона отсоединять?Я просто отсоединил и потом в ремонт носил.
Теперь даже устанавливать боюсь, вдруг что опять не так сделаю. Или там просто "далее"?
Painkiller писал(а): обновляет/прошивает? там ещё тип нельзя кабель от телефона отсоединять?
Я просто отсоединил и потом в ремонт носил.
тогда понятно
Там же дают все инструкции и заранее предупреждают возможных проблемах при их несоблюдении :wink: И трижды переспрашивают: "исполнили ли Вы их в точности?"
Ну, не совсем "далее", но просто:
1. Заряжаешь телефон на всякий случай
2. Делаешь резервное копирование (через PC Suit)
3. Запускаешь Software update, читаешь внимательно все, что там написано (хотя я, вроде, все сказал).
4. Запускаешь обновление. Телефон не трогаешь вообще! (про шнур вообще молчу)
5. Все. Восстанавливаешь данные через ту же опцию резервного копирования в PC Suit.
Займет все предприятие минут 20-30 МАКСИМУМ.
Добавлено спустя 47 минут 4 секунды:
Painkiller, и как успехи?
Разбираемся с причинами noclassdeffounderror в Java
NoClassDefFoundError в Java возникает, когда виртуальная машина Java не может найти определенный класс во время выполнения, который был доступен во время компиляции.
Например, если у нас есть вызов метода из класса или доступ к любому статическому члену класса, и этот класс недоступен во время выполнения, JVM сгенерирует NoClassDefFoundError.
Важно понимать, что это отличается от ClassNotFoundException, который появляется при попытке загрузить класс только во время выполнения, а имя было предоставлено во время выполнения, а не во время компиляции. Многие Java-разработчики смешивают эти две ошибки и запутываются.
NoClassDefFoundError возникнет, если класс присутствовал во время компиляции, но не был доступен в java classpath во время выполнения. Обычно появляется такая ошибка:
Разница между java.lang.NoClassDefFoundError и ClassNotFoundException в Java
[ads-pc-3]
java.lang.ClassNotFoundException и java.lang.NoClassDefFoundError оба связаны с Java Classpath, и они полностью отличаются друг от друга.
ClassNotFoundException возникает, когда JVM пытается загрузить класс во время выполнения, т.е. вы даете имя класса во время выполнения, а затем JVM пытается загрузить его, и если этот класс не найден, он генерирует исключение java.lang.ClassNotFoundException.
Тогда как в случае NoClassDefFoundError проблемный класс присутствовал во время компиляции, и поэтому программа успешно скомпилирована, но не доступна во время выполнения по любой причине.
Приступим к решению ошибки java.lang.NoClassDefFoundError.
Нам нужно добавить NoClassDefFoundError в Classpath или проверить, почему он не доступен в Classpath. Там может быть несколько причин, таких как:
- Класс недоступен в Java Classpath.
- Возможно, вы запускаете вашу программу с помощью jar, а класс не определен в атрибуте ClassPath.
- Любой сценарий запуска переопределяет переменную среды Classpath.
Поскольку NoClassDefFoundError является подклассом java.lang.LinkageError, он также может появиться, если библиотека может быть недоступна. - Проверьте наличие java.lang.ExceptionInInitializerError в файле журнала. NoClassDefFoundError из-за сбоя инициализации встречается довольно часто.
- Если вы работаете в среде J2EE, то видимость Class среди нескольких Classloader также может вызвать java.lang.NoClassDefFoundError.
Примеры
NoClassDefFoundError в Java из-за исключения в блоке инициализатора
Это еще одна распространенная причина java.lang.NoClassDefFoundError, когда ваш класс выполняет некоторую инициализацию в статическом блоке и если статический блок генерирует исключение, класс, который ссылается на этот класс, получит NoclassDefFoundError.
Смотрите в журнале java.lang.ExceptionInInitializerError, потому что это может вызвать java.lang.NoClassDefFoundError: Could not initialize class.
Как и в следующем примере кода, во время загрузки и инициализации класса, пользовательский класс генерирует Exception из статического блока инициализатора, который вызывает ExceptionInInitializerError при первой загрузке пользовательского класса в ответ на новый вызов User ().
[ads-pc-3]
Ошибка может возникать на Windows XP, из-за отсутствия нужных библиотек для Java.
Если Ваша проблема остаётся актуальной, запросите поддержку у TLauncher:
Скриншот ошибки NPE
Что это за ошибка java.lang.nullpointerexception
Номер строки с ошибкой
Что в отношении обычных пользователей, то появление ошибки java.lang.nullpointerexception у вас на ПК сигнализирует, что у вас что-то не так с функционалом пакетом Java на вашем компьютере, или что программа (или онлайн-приложение), работающие на Java, функционируют не совсем корректно. Если у вас возникает проблема, при которой Java апплет не загружен, рекомендую изучить материал по ссылке.
Как избавиться от ошибки java.lang.nullpointerexception? Способы борьбы с проблемой можно разделить на две основные группы – для пользователей и для разработчиков.
Для пользователей
Если вы встретились с данной ошибкой во время запуска (или работы) какой-либо программы (особенно это касается java.lang.nullpointerexception minecraft), то рекомендую выполнить следующее:
Java ошибка в Майнкрафт
Для разработчиков
Разработчикам стоит обратить внимание на следующее:
- Вызывайте методы equals(), а также equalsIgnoreCase() в известной строке литерала, и избегайте вызова данных методов у неизвестного объекта;
- Вместо toString() используйте valueOf() в ситуации, когда результат равнозначен;
- Применяйте null-безопасные библиотеки и методы;
- Старайтесь избегать возвращения null из метода, лучше возвращайте пустую коллекцию;
- Применяйте аннотации @Nullable и @NotNull;
- Не нужно лишней автоупаковки и автораспаковки в создаваемом вами коде, что приводит к созданию ненужных временных объектов;
- Регламентируйте границы на уровне СУБД;
- Правильно объявляйте соглашения о кодировании и выполняйте их.
try / catch / finally и исключения
Думаю, вряд ли найдется Java-разработчик, который хотя бы не слышал об исключениях. В принципе, они не являются исключительным свойством Java, есть они и в Delphi, и в C++. Однако в Java исключения используются особенно широко. И чаще всего с ними связано немало ошибок. Основная цель этой статьи – систематизация информации об исключениях, их обработке и т.п. А именно:
Исключение как явление
Что такое вообще исключение? Это сигнал о нестандартной – исключительной – ситуации. Ситуации могут быть самые различные – ожидаемые или нет, разной степени критичности. И относиться к этим ситуациям, естественно, приходится по-разному.
Как и всё в Java, исключения тоже представленны в виде классов. Корнем иерархии служит класс java.lang.Throwable , дословно – "бросаемый". Его прямыми наследниками являются java.lang.Exception и java.lang.Error, от которых и унаследованы все остальные исключения. И от которых рекомендуется наследовать собственные.
Хочу подчеркнуть, что исключения не есть нечто из ряда вон выходящее. Это нормальный механизм. Потому не стоит стараться избегать их использования любой ценой. И тем более не стоит стараться избегать исключений в конструкторах, к чему склонны разработчики, хорошо знакомые с С++. Ввиду наличия сборщика мусора утечек памяти в этом случае не будет. Разве что очень постараться, я имею в виду намеренно.
Теперь рассмотрим типы исключений ближе.
Классификация исключений
Как я уже упоминал, есть два "базовых" типа исключений – java.lang.Exception и java.lang.Error. Я бы сказал, что различаются степенью критичности. Не, разумеется, оба типа могут быть перехвачены, ибо перехватывается исключение начиная с уровня java.lang.Throwable . Это разделение скорее логическое. Если произошло что-то серьезное – не найден метод, который надо вызвать, закончилась память, переполнение стека, в общем, что-то, после чего восстановить нормальную работу уже вряд ли реально – это ошибка, java.lang.Error. Если продолжение работы теоретически возможно – это исключение, java.lang.Exception.
Поскольку исключения – точно такие же классы, в них можно включать и собственные переменные, и даже какую-то логику. Увлекаться, правда, не стоит. Дело в том, что исключение – класс все-таки выделенный. При создании Throwable существуют большие накладные расходы – заполнение стека вызова. Это достаточно длительная процедура. И потому создавать исключение просто так – себе дороже. Его нужно создавать только тогда, когда без него не обойтись, когда оно точно будет выброшено. Проще это делать сразу вместе с директивой throw .
А вот держать в классе исключения какую-то информацию, которая позволит его обработать – вполне допустимо. Передавать эту информацию лучше через конструктор.
Итак, приступим к более подробному рассмотрению. Первый базовый тип –
java.lang.Exception
Исключения этого типа я бы охарактерировал так – они возникают в ситуациях, которые нам неподконтрольны. Скажем, десериализуем мы класс, а данные в неверном формате. И мы с этим ничего не можем сделать, кроме как адекватно отреагировать.
Метод может декларировать любое количестко исключений. Нет, любое – это, наверное, слишком сильно сказано. Если мне не изменяет память, количество исключений ограничено 64K – 65536 штук. Для меня это уже означает, что я могу декларировать столько исключений, сколько мне заблагорассудится.
Перейдем теперь к последнему типу –
java.lang.Error
Как я уже упоминал, это критические ошибки, после которых восстановить нормальную работу практически нереально. В самом деле – ну что сделаешь при переполнении стека? Или если не найден метод? Или если вызван абстрактный метод? Или в случае ошибки в байт-коде класса? Абсолютно ничего. По крайней мере, без серьезного вмешательства человека, который может заменить библиотеку, например. Или поменять classpath .
В некоторых случаях ситуация не столь критична. Скажем, нехватка памяти, вызывающая java.lang.OutOfMemoryError . Если эта ошибка произошла в момент выделения большого объема памяти – например, при создании массива, – ее можно перехватить и попытаться выделить память в меньших объемах, изменив каким-то образом алгоритм, который будет эту память использовать.
Или, скажем, в случае, когда не JVM поддерживает системную кодировку – при попытке создать InputStreamReader без указания кодировки будет выброшена ошибка. Однако нужна ли нам системная кодировка и насколько для нас критично ее отсутствие – решать нам.
С классификацией закончили, переходим к следующему вопросу.
Инициация исключений
А вопрос следующий – что и когда бросать.
Представим себе, что у вас создалась исключительная ситуация и работать код дальше не может. Какой именно тип исключения использовать?
При написании бизнес-логики – в особенности это касается библиотек – часто бывает полезным создать собственный тип исключения. Просто для того, чтобы дать возможность обрабатывать ваши исключения отдельно от остальных. Подробнее об обработке – в следующем разделе.
Пара слов насчет приведенного примера – null в качестве параметра. Теоретически в этой ситуации можно бросить два исключения – NullPointerException и IllegalArgumentException . Нескотря на кажущуюся очевидность выбора я лично предпочитаю второй вариант. На мой взгляд NullPointerException должна бросать исключительно виртуальная машина. Если же я сам проверил значение и убедился, что оно равно null , а этого быть не должно – гораздо более информативно использовать IllegalArgumentException , если это значение аргумента, или же IllegalStateException – если это значение члена класса.
Ну ладно, что бросить именно – это мы как-нибудь определим. Но иногда возникает какое-то иррациональное желание не только бросить исключение, но и как-то его конкретизировать, указав причину. Не, можно, конечно, и по исключению на каждую ошибку создать, но сойти с ума намного проще и быстрее.
В этом случае может выручить механизм т.н. exception chaining – связывания исключений. Практически у каждого класса исключения есть конструктор, принимающий в качестве параметра Throwable – причину исключительной ситуации. Если же такого конструктора нет – у все того же Throwable , от которого унаследованы все исключения, есть метод initCause(Throwable) , который можно вызвать ровно один раз. И передать ему исключение, явившееся причиной того, что было инициировано следующее исключение.
Зачем это нужно. Дело в том, что хорошо спроектированный код – он как черный ящик. У него есть свои интерфейсы, определенное поведение, набор исключительных ситуаций, наконец. А что происходит внутри – это не играет роли для того, что находится снаружи. Более того – иногда может сыграть и обратный эффект. Причин для ошибки может быть добрый десяток, и ловить их все отдельно и так же обрабатывать. Чаще всего просто не нужно. Именно потому проще определить, например, свое исключение (ну или использовать имеющееся, не суть важно) и бросить именно его, указав как причину то, которое мы поймали. И волки сыты, и пользователям кода работы меньше.
Ну вот, от инициации исключений мы плавно переходим к их обработке.
Обработка исключений
Казалось бы, чего проще? Написал catch(Throwable th) – и всё. Однако именно от этого я их хочу предостеречь.
Во-первых, как я уже говорил выше, ловить исключения времени выполнения – дурной тон. Они свидетельствуют об ошибках. Ловить java.lang.Error или производные стоит только если вы точно знаете, что делаете. Восстановление после таких ошибок не всегда возможно и почти всегда нетривиально.
Во-вторых – как именно обрабатывать? Я об этом подробно писал в статье о качестве кода, раздел Обработка исключений, но повторюсь. По каждому пойманому исключению необходимо принимать решение. Просто проглотить его или вывести в консоль – самое неприятное, что можно придумать. А этим грешат, к сожалению, многие. Человек читает XML из файла, получает исключение, глотает его – и пытается дальше работать с этим XML так, как будто ничего не произошло. Естественно получает NullPointerException , поскольку класс, который он использует, не инициализировался. Ошибка разработчика, хотя и не столь очевидная.
Почему я говорил о том, что стоит заводить свои типы исключений – так вы проще сможете их выделить на стадии обработки. Представьте себе, что существуют пять причин, по которым может быть выброшено исключение, и во всех пяти случаях бросается java.lang.Exception . Вы же спятите разбираться, чем именно это исключение вызвано. А если это будет пять разных типов – тут уже проще простого. На каждый – свой блок catch .
И третье – что делать с иерархиями исключений. Пусть у вас метод может выбросить как IOException , так и Exception . Так вот, совершенно не все равно, в каком порядке будут стоять блоки catch , поскольку они обрабатываются ровно в той последовательности, как объявлены. И если первым будет catch(Exception ex) – до второго ( catch(IOException ioex) ) управление просто не дойдет. Компилятор об этом, конечно, предупредит, более того – это считается ошибкой. Тем не менее об этом стоит помнить.
Следующее, чего бы я хотел коснуться –
Перехват исключений, вызвавших завершение потока
При использовании нескольких потоков бывают ситуации, когда надо знать, как поток завершился. В смысле – если это произошло из-за исключения, то из-за какого именно. Для этой цели начиная с версии Java 5 существует специальный интерфейс – Thread.UncaughtExceptionHandler . Его реализацию можно установить нужному потоку с помощью метода setUncaughtExceptionHandler . Можно также установить обработчик по умолчанию с помощью статического метода Thread.setDefaultUncaughtExceptionHandler .
Интерфейс Thread.UncaughtExceptionHandler имеет один единственный метод – uncaughtException(Thread t, Throwable e) – в который передается экземпляр потока, завершившегося исключением, и экземпляр самого исключения. Восстановить работу потока, естественно, уже не удастся, но зафиксировать факт его ненормального завершения таким образом можно.
Следующее, о чем я хотел бы поговорить – сама конструкция try / catch / finally .
Конструкция try / catch / finally – тонкости
С блоком try , думаю, вопросов не возникает. С блоком catch – надеюсь, уже тоже нет. Остается блок finally . Что это, и с чем его едят?
Блок finally идет в самом конце конструкции try / catch / finally . Ключевая его особенность в том, что он выполняется всегда, вне зависимости от того, сработал catch или нет.
Зачем это нужно. Посмотрите вот на этот фрагмент кода:
Казалось бы все в порядке. А что будет, если, например, при вызове rs.first() произойдет исключение? Да, оно обработается. Однако ни ResultSet , ни Statement , ни Connection закрыты не будут. Последствия весьма печальны – исчерпание открытых курсоров, соединений в пуле и т.п.
Можно, конечно, поместить этот же код и в блок catch . Однако дублировать код – не лучшая идея. Правильнее вынести код закрытия в блок finally , в этом случае он будет исполнен как в случае возникновения исключения, так и в случае, когда этого не происходит.
Рассмотрим еще один пример:
Вопрос на засыпку – каков будет результат? Выполняем тест и получаем:
Т.е. в обоих случаях результат будет одинаковый, причем не тот, которого можно было бы ожидать! Почему так происходит? В первом случае – из блока try должно вернуться значение 6 – длина переданной строки. Однако выполняется блок finally , в котором возвращается 0. В результате исходное значение теряется. Во втором случае – попытка вызвать toString() при переданном значении null приведет к исключению – NullPointerException . Это исключение будет перехвачено, т.к. является наследником Exception . Из блока catch должно вернуться значение -1, однако выполняется блок finally и возвращается опять-таки 0, а -1 – теряется!
Точно так же блок finally может вызвать потерю исключений. Посмотрите вот на этот пример:
Этот тест очень часто давался на интервью. И правильно отвечали единицы. Между тем – результатом его выполнения будет вывод в консоль b. И только. После инициации первого исключения – new Exception("a") – будет выполнен блок finally , в котором будет брошено исключение new IOException("b") . И именно это исключение будет поймано и обработано. Исходное же исключение теряется.
Хотелось бы затронуть еще один момент. В каких комбинациях могут существовать блоки try , catch и finally ? Понятно, что try – обязателен. Он может быть совместно с catch , либо с catch и finally одновременно. Отдельно try не используется. А есть ли еще варианты?
Есть. try может быть в паре с finally , без catch . Работает это точно так же – после выхода из блока try выполняется блок finally . Это может быть полезно, например, в следующей ситуации. При выходе из метода вам надо произвести какое-либо действие. А return в этом методе стоит в нескольких местах. Писать одинаковый код перед каждым return нецелесообразно. Гораздо проще и эффективнее поместить основной код в try , а код, выполняемый при выходе – в finally .
И последняя тема –
Отсутствие транзакционности
В самом начале я упоминал о том, что организовать утечку памяти при использовании исключений в конструкторах сложно. На самом деле – можно. Смотрим на пример.
Итак, что тут происходит. В конструкторе мы присваиваем ссылку на созданный объект статической переменной. Дальше мы инициализируем одно поле и. бросаем исключение. Я это делаю намеренно, однако это может произойти и в результате выполнения кода конструктора. В методе main это исключение обрабатывается. Однако ссылка на объект – существует! В чем можно убедиться, выполнив приведенный код:
Переменная метода main равна null , как и положено. А вот статическая переменная self – нет. Через нее можно получить доступ к объекту, инициализация которого была прервана исключением. И объект этот, естественно, в неверном состоянии. Вот она – утечка памяти. Объект не будет удален до тех пор, пока на него есть ссылка.
Пример этот искуственный, но лишь до известной степени. Он говорит об очень важной особенности исключений:
Cвойством транзакционности исключения не обладают – действия, произведенные в блоке try до возникновения исключения, не отменяются поcле его возникновения.
И это необходимо учитывать. Применительно к приведенному примеру – стоит все операции, могущие привести к исключению, выполнять как можно раньше. Например, проверять переданные параметры сразу же. В некоторых случаях для отмены уже произведенных действий может пригодиться блок finally . А если очень надо где-то сохранить ссылку на создаваемый объект, причем сделать это необходимо в конструкторе – лучше всего оставить это напоследок, когда весь критический код уже выполнен.
Ну, вот и все. Думаю, большая часть этого материала вам была знакома. Во всяком случае, надеюсь на это. Моей целью было просто упорядочить информацию для тех, кто с исключениями пока еще знаком поверхностно. Всем спасибо!
Читайте также: