Контроль исключений
Вопрос, скорее, по стандарту языка Java и его реализации. Как-то пытался изучать Java и помню, что исключения являются частью декларации функции, т. е. указывается, какие конкретно исключения можно от нее ожидать.
Внимание, вопрос! :) Как это контролируется компилятором? Ведь исключения могут вызывать не только пользовательские или библиотечные процедуры, но и процессор, например. Если AV не может возникнуть - в Java нет адресов и адресной арифметики, то как быть с делением на ноль, например? Т. е. если я напишу в теле функции деление на переменную без проверки, заругается компилятор или нет? Если нет - что будет, если в процессе выполнения кода деление на 0 все-таки произойдет?
Внимание, вопрос! :) Как это контролируется компилятором? Ведь исключения могут вызывать не только пользовательские или библиотечные процедуры, но и процессор, например. Если AV не может возникнуть - в Java нет адресов и адресной арифметики, то как быть с делением на ноль, например? Т. е. если я напишу в теле функции деление на переменную без проверки, заругается компилятор или нет? Если нет - что будет, если в процессе выполнения кода деление на 0 все-таки произойдет?
Цитата:
Originally posted by Freeman
Вопрос, скорее, по стандарту языка Java и его реализации. Как-то пытался изучать Java и помню, что исключения являются частью декларации функции, т. е. указывается, какие конкретно исключения можно от нее ожидать.
Внимание, вопрос! :) Как это контролируется компилятором? Ведь исключения могут вызывать не только пользовательские или библиотечные процедуры, но и процессор, например. Если AV не может возникнуть - в Java нет адресов и адресной арифметики, то как быть с делением на ноль, например? Т. е. если я напишу в теле функции деление на переменную без проверки, заругается компилятор или нет? Если нет - что будет, если в процессе выполнения кода деление на 0 все-таки произойдет?
Вопрос, скорее, по стандарту языка Java и его реализации. Как-то пытался изучать Java и помню, что исключения являются частью декларации функции, т. е. указывается, какие конкретно исключения можно от нее ожидать.
Внимание, вопрос! :) Как это контролируется компилятором? Ведь исключения могут вызывать не только пользовательские или библиотечные процедуры, но и процессор, например. Если AV не может возникнуть - в Java нет адресов и адресной арифметики, то как быть с делением на ноль, например? Т. е. если я напишу в теле функции деление на переменную без проверки, заругается компилятор или нет? Если нет - что будет, если в процессе выполнения кода деление на 0 все-таки произойдет?
Вылетит эксепшен. Компилятор при компиляции лишь проверяет что если в коду будет вылетать throw new хххException , то он обязательно должен быть обработан одной из функции,которые в результате вызова которых и произошел эксепшен. Короче если ты сделал несколько подвызовов и внутри их произошел эксепшен, то необходимо его обработать.
Насчет деления на ноль, то здесь очень просто. Это действие не требует обязательной обработки, оно будет словлено виртуальной машиной. вылетит так сказать runtime error =). Вот так.
все верно. для большей ясности процитирую один из манов:
Цитата:
Дело в том, что спецификация JLS делит все исключения на проверяемые (checked), те, которые проверяет компилятор, и непроверяемые (unchecked). При проверке компилятор замечает необработанные в методах и конструкторах исключения и считает ошибкой отсутствие в заголовке таких методов и конструкторов пометки throws.
Так вот, исключения класса RuntimeException и его подклассов, одним из которых является ArithmeticException, непроверяемые, для них пометка throws необязательна. Еще одно большое семейство непроверяемых исключений составляет класс Error и его расширения.
Почему компилятор не проверяет эти типы исключений? Причина в том, что исключения класса RuntimeException свидетельствуют об ошибках в программе, и единственно разумный метод их обработки — исправить исходный текст программы и перекомпилировать ее. Что касается класса Error, то эти исключения очень трудно локализовать и на стадии компиляции невозможно определить место их появления.
Напротив, возникновение проверяемого исключения показывает, что программа недостаточно продумана, не все возможные ситуации описаны. Такая программа должна быть доработана, о чем и напоминает компилятор.
Так вот, исключения класса RuntimeException и его подклассов, одним из которых является ArithmeticException, непроверяемые, для них пометка throws необязательна. Еще одно большое семейство непроверяемых исключений составляет класс Error и его расширения.
Почему компилятор не проверяет эти типы исключений? Причина в том, что исключения класса RuntimeException свидетельствуют об ошибках в программе, и единственно разумный метод их обработки — исправить исходный текст программы и перекомпилировать ее. Что касается класса Error, то эти исключения очень трудно локализовать и на стадии компиляции невозможно определить место их появления.
Напротив, возникновение проверяемого исключения показывает, что программа недостаточно продумана, не все возможные ситуации описаны. Такая программа должна быть доработана, о чем и напоминает компилятор.
Цитата:
Originally posted by gufy
Дело в том, что спецификация JLS делит все исключения на проверяемые (checked), те, которые проверяет компилятор, и непроверяемые (unchecked). При проверке компилятор замечает необработанные в методах и конструкторах исключения и считает ошибкой отсутствие в заголовке таких методов и конструкторов пометки throws.
Дело в том, что спецификация JLS делит все исключения на проверяемые (checked), те, которые проверяет компилятор, и непроверяемые (unchecked). При проверке компилятор замечает необработанные в методах и конструкторах исключения и считает ошибкой отсутствие в заголовке таких методов и конструкторов пометки throws.
Спасибо, становится теплее. Я тут первоисточник изучать пытаюсь, то бишь Оберон. Вот и хочется понять: программирование без исключений - монастырь, или действительно можно без них обойтись.
Цитата:
Originally posted by Zhilin Mike
Вылетит эксепшен. Компилятор при компиляции лишь проверяет что если в коду будет вылетать throw new хххException , то он обязательно должен быть обработан одной из функции,которые в результате вызова которых и произошел эксепшен. Короче если ты сделал несколько подвызовов и внутри их произошел эксепшен, то необходимо его обработать.
Насчет деления на ноль, то здесь очень просто. Это действие не требует обязательной обработки, оно будет словлено виртуальной машиной. вылетит так сказать runtime error =). Вот так.
Вылетит эксепшен. Компилятор при компиляции лишь проверяет что если в коду будет вылетать throw new хххException , то он обязательно должен быть обработан одной из функции,которые в результате вызова которых и произошел эксепшен. Короче если ты сделал несколько подвызовов и внутри их произошел эксепшен, то необходимо его обработать.
Насчет деления на ноль, то здесь очень просто. Это действие не требует обязательной обработки, оно будет словлено виртуальной машиной. вылетит так сказать runtime error =). Вот так.
Не совсем верно. Напишите в теле функции
Код:
throw new NullPointerException()
В этом случае компилятор не потребует ни для самой функции определять суффикс throws NullPointerException. Ни для вызывающей ее функции сделать блок try ... catch
Так что смотрите пост про checked и unchecked исключения.
Цитата:
Originally posted by S_T
Не совсем верно. Напишите в теле функции
В этом случае компилятор не потребует ни для самой функции определять суффикс throws NullPointerException. Ни для вызывающей ее функции сделать блок try ... catch
Так что смотрите пост про checked и unchecked исключения.
Не совсем верно. Напишите в теле функции
Код:
throw new NullPointerException()
В этом случае компилятор не потребует ни для самой функции определять суффикс throws NullPointerException. Ни для вызывающей ее функции сделать блок try ... catch
Так что смотрите пост про checked и unchecked исключения.
Ну да... Как бы оно будет словлено компилятором. Как и деление на нуль. Просто по философии эти эксепшены просходят в основном так сказать не зависимо от нас. Поэтому все они должны быть обработаны машиной.