Checked-exceptions, добро или зло?

← →
iZEN © (2005-08-30 23:42) [0]

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

Либо другая точка зрения: объявить в принципе можно (лучше отразить в документации и не мусорить код), заставлять обратить внимание на это на этапе компиляции - не нужно (Unchecked exceptions).

Первый подход исповедует Java, а второй - C# и Delphi.
Кто что считает правильным?
Может быть есть другие варианты?

P.S. Аналог ветки на RSDN.ru, но это не важно. Имейте собственное мнение.

← →
Джо © (2005-08-30 23:46) [1]

> P.S. Аналог ветки на RSDN.ru, но это не важно.

А можно ссылку, если есть. Охота посмотреть.

← →
Джо © (2005-08-30 23:48) [2]

> [1] Джо © (30.08.05 23:46)

Сорри, сонный - туплю. Уже нашел. Кому нужно: http://rsdn.ru/Forum/?mid=1279454

← →
Джо © (2005-08-30 23:49) [3]

Заоффтопил тут все :(
Моя личная точка зрения - достаточно отразить в докумментации.

← →
Ломброзо © (2005-08-30 23:50) [4]

iZEN © (30.08.05 23:42)

Всего не предусмотришь, посему второе. А в Java пишем throws Throwable и баста. Кстати, в ++ эти самые throws в спецификацию введены, но, афаик, ни в одном компиляторе по-человечески не реализованы, ибо никому не сдались.

← →
лентяй (2005-08-31 00:00) [5]

Ломброзо © (30.08.05 23:50) [4]

писать throws Throwable - лениво

лучше в ЖБилдере тыкнуть в менюшку "surround with try/catch"
поэтому, первый. Checked-exceptions так и заставляют заниматься их отловом.

← →
DiamondShark © (2005-08-31 10:04) [6]

Я не понимаю, зачем декларировать исключения.
Что это даёт, кроме лишнего геморроя и усложнения компиляторов?

← →
iZEN © (2005-08-31 10:31) [7]

Ну я-то думаю, что подход в java прильный: лучше знать о проблеме, попытться её как-то решить, вместо замалчивания и утаивания.

Кстати, в java есть также и unckecked-exception"s - это RuntimeException и все потомки (NullPointerException, ArithmeticException, IndexOutOfBoundsExeption и др.), которые возникают во время работы и не ловятся компилятором. Их можно перехватывать в блоке try/catch/finally, но объявление их в сигнатуре метода (throw) ничего не даёт для вызывающего кода, в то время как объявление других checked-exceptions прямо-таки заставляет компилятор тыкать носом программистя, пишущего вызывающий код: исключение пробрасывай выше - объявляй в сигнатуре собственного метода то же самое, или обрабатывай.

← →
DiamondShark © (2005-08-31 11:10) [8]

> прямо-таки заставляет компилятор тыкать носом программистя

А зачем?

← →
Ермак © (2005-08-31 11:54) [9]

По моему мнению, обработка исключений скорее вредна, чем полезна. Недаром Никлаус Вирт исключил ее из своего последнего языка Оберон. Любой механизм обработки исключений - это нелокальный переход, аналог GOTO, что не есть хорошо. На этапе выполнения все ошибки уже не должны быть ошибками - алгоритм должен быть детерминирован и обоснован, отрабатывая все возможные ситуации как обычное условное ветвление. Самый лучший механизм борьбы с ошибками - неотключаемый контроль диапазонов массивов, строгий динамический контроль типов, проверка предусловий каждой функции с помощью неотключаемого ASSERT.
Так, наример, сделано в среде BlackBox языка Компонентный Паскаль.

← →
Игорь Шевченко © (2005-08-31 11:58) [10]

Ермак © (31.08.05 11:54) [9]

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

Условное ветвление есть причина нечитаемости кода программы.

> проверка предусловий каждой функции с помощью неотключаемого
> ASSERT.

А что, ASSERT не является источником исключения ?

← →
DiamondShark © (2005-08-31 12:15) [11]

> А что, ASSERT не является источником исключения ?

ASSERT является источником аварийного завершения.

> Ермак © (31.08.05 11:54) [9]

Исключения -- это не ошибки.

← →
Ермак © (2005-08-31 12:24) [12]

>А что, ASSERT не является источником исключения ?

Я имею в виду не отсутсвие механизмов исключений, а отсутствие синтаксических средств для их нелокальной обработки. Так как поощряет раздолбайство в программировании. Все привыкли к тому, что AV - нормальная вещь, и программа после нее как ни в чем не бывало возобновляется. Av - это ненормально, и случаи, в которых они могут возникнуть, необходимо предвидеть еще при составлении алгоритма.

← →
Esu © (2005-08-31 12:31) [13]

> необходимо предвидеть еще при составлении алгоритма

И что, получается ? :)

← →
Игорь Шевченко © (2005-08-31 12:35) [14]

> Так как поощряет раздолбайство в программировании. Все привыкли
> к тому, что AV - нормальная вещь, и программа после нее
> как ни в чем не бывало возобновляется.

Смелое утверждение, но очень далекое от истины.

← →
Ермак © (2005-08-31 12:36) [15]

> И что, получается ? :)
Стараюсь :-)

← →
Ермак © (2005-08-31 12:39) [16]

Просто большинство программистов - самоучки (и я в том числе). Даже у нас в ВУЗе почти все преподы такие. Из физики в основном пришли. Если бы еще со школы в физмат-классах давали алгоритмику и дискретную математику, а не Excel и Word, массовое ПО работало бы лучше. А то до истин приходится доходить медленно, наступая на всякие грабли...

← →
Игорь Шевченко © (2005-08-31 12:42) [17]

Ермак © (31.08.05 12:39) [16]

> Если бы еще со школы в физмат-классах давали алгоритмику
> и дискретную математику, а не Excel и Word, массовое ПО
> работало бы лучше.

Массовое ПО и без того неплохо работает по одной простой причине - у него тестировщиков много.

← →
fedotawa (2005-08-31 12:46) [18]

"...я думаю, что любой язык, который стремится к господствующему положению во всех областях, должен обеспечить широкую основу для нескольких методов, включая объектно-ориентированное программирование (на основе иерархии классов) и обобщенное программирование (параметризированные типы и алгоритмы). В частности, необходимо обеспечить хорошие средства для создания программ из отдельных (независимых) частей (возможно, написанных на различных языках). Я также думаю, что для управления сложным процессом обработки ошибок необходимы исключения. Язык, в котором отсутствуют такие средства вынуждает его пользователей моделировать их (что ведет к дополнительным ошибкам и затратам)."

Б. Страуструп

← →
DiamondShark © (2005-08-31 12:46) [19]

> Av - это ненормально, и случаи, в которых они могут возникнуть,
> необходимо предвидеть еще при составлении алгоритма.

В типобезопасных языках и исполняющих средах AV не бывает.
Претензии не по адресу.

← →
Игорь Шевченко © (2005-08-31 12:59) [20]

DiamondShark © (31.08.05 12:46) [19]

> В типобезопасных языках и исполняющих средах AV не бывает.

В .Net вот встретилось однажды.

← →
DiamondShark © (2005-08-31 13:05) [21]

> В .Net вот встретилось однажды.

Где именно?

← →
Игорь Шевченко © (2005-08-31 13:25) [22]

DiamondShark © (31.08.05 13:05) [21]

При отладке .Net"овского проекта. Где именно - искать не стал.

← →
Evgeny V © (2005-08-31 13:40) [23]

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

> DiamondShark © (31.08.05 12:46) [19]
>
> > Av - это ненормально, и случаи, в которых они могут возникнуть,
>
> > необходимо предвидеть еще при составлении алгоритма.
>
> В типобезопасных языках и исполняющих средах AV не бывает.
> Претензии не по адресу.

Java 2 думаю отвечает термину типобезопасного языка - но тем не менее exception по ссылке null в ней может возникнуть, так же могут возникнуть и другие виды исключений, как ошибка программиста например, сбой в работе оборудование - это второй вариант. И возможно они не всегда были бы нужны, в иных случаях смотрится скорее возврат ошибочного результата, но раз уж может возникнуть exception, то я хотел бы знать о нем, в документации как минимум, да и в виде объявления в коде тоже не плохо.

← →
Igorek © (2005-08-31 13:47) [24]

> Игорь Шевченко © (31.08.05 12:59) [20]
> DiamondShark © (31.08.05 12:46) [19]
> > В типобезопасных языках и исполняющих средах AV не бывает.
> В .Net вот встретилось однажды.
А точно AV? Не NullReferenceException?

← →
Игорь Шевченко © (2005-08-31 13:55) [25]

Igorek © (31.08.05 13:47) [24]

Точно. Проект в Delphi 2005, VCL.Net

← →
Mystic © (2005-08-31 13:56) [26]

Java работает в своем собствунном окружении. Естественно там можно отловить все типы исключений :) А вот в Delphi с этим сложнее. Исключение может породить операционная система, библиотека DLL, другой пакет, ... Так что всеобьемлющая проверка кажется мне нереализуемой.

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

← →
Суслик © (2005-08-31 14:05) [27]

> [26] Mystic © (31.08.05 13:56)

в java есть разные исключения.
Потомки RuntimeException (если не ошибаюсь) перехватывать и декларировать не обязательно. Но таких исключений в действительно не много. Например - деление на ноль.

Все остальные исключения нужно декларировать и обязательно перехватывать. Таких классов большинство.

----------

Мне в java подход нравится больше всего. Удобство заключается в том, что программист просто ОБЯЗАН предусмотреть возможную обработку исключительной ситуации. Имхо это повышает качество кода и строгость библиотек классов.

← →
Evgeny V © (2005-08-31 14:07) [28]

> Mystic © (31.08.05 13:56) [26]
> Java работает в своем собствунном окружении. Естественно
> там можно отловить все типы исключений :) А вот в Delphi
> с этим сложнее. Исключение может породить операционная система,
> библиотека DLL, другой пакет, ... Так что всеобьемлющая
> проверка кажется мне нереализуемой.

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

> Java 2 думаю отвечает термину типобезопасного языка - но
> тем не менее exception по ссылке null в ней может возникнуть

exception по ссылке null -- это не AV.
После того, как перехвачен AV, не может быть никакой уевренности, что код и/или данные не повреждены.
Совершенно разные вещи.

> да и в виде объявления в коде тоже не плохо

А зачем?
Как элемент документации -- понятно. А со строгой проверкой компилятором зачем?
Тем более, что возникает непоследовательность: декларировать всякие деления на ноль или переполнения при использовании арифметических выражений никто не заставляет, а вот какой-нибудь IO error -- уже обязан задекларировать.
Зачем эти нагромождения?

Объявление throws - несомненное преимущество языка Java.
Это действительно позволяет писать более надежные программы.
Для лентяев: это не усложняет написание программ, так как все IDE для Java очень хорошо понимают эти throws и никаких проблем это не создает. В результате же ты можешь быть уверен, что в плане exception у тебя все правильно.

Совсем недаром application сервера стали писать на Java - они очень стабильны и их тяжело уронить.

> Удобство заключается в том, что программист просто ОБЯЗАН
> предусмотреть возможную обработку исключительной ситуации.

А в чём удобство-то?

> [31] DiamondShark © (31.08.05 14:25)

Что такое удобство? Абсолютного удобства не бывает. Но хорошая комбинация удобства разработчика библиотеки и пользователя библиотеки в java достигается весьма неплохо.

Т.е. разработчик библиотеки может заставить пользователя библиотеки пользоваться бибиотекой правильно, зная все возможные проблемы библиотеки.

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

Т.е. для большого коллектива throws очень хорошо.

Igorek © (31.08.05 14:29) [32]

Тебе кофейной гущи не выслать наложенным платежом ? Я неуправляемый код не использовал, за все остальное ничего сказать не могу. Впрочем, CLR сама использует неуправляемый код, так что в итоге, разумеется, ты прав.

> Суслик © (31.08.05 14:32) [33]

А можно увидеть описание конкретной проблемы и то, как она решается?
Без метафизики и обтекаемых формулировок?

> А можно увидеть описание конкретной проблемы и то, как она
> решается?

Какой конкретно проблемы? Ты про что?
Поставь тестовый пример. Тогда и решу.

> Суслик © (31.08.05 14:39) [36]

То есть про "удобство" ты просто с чужих слов свистишь, иначе бы тебе не составило труда найти пример, типа, вот как я раньше делал, а вот как теперь.
Так?

> DiamondShark

> А в чём удобство-то?

AV - сорри если не прав, я это понимаю как Access Violation, в этом случае
про AV по nil pointer я взял из хелпа по Дельфи 6
VCL Reference
EAccessViolation

EAccessViolation is raised when an application

Dereferences a nil pointer.
Writes to memory reserved for executable code.
Attempts to access a memory address for which there is no virtual memory allocated to the application.

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

> [37] DiamondShark © (31.08.05 14:43)

Что значит свищу? Было у меня увлечение javой пол года назад. Прочел пару "классических" книг по ней. Посмотрел версии 1.4.0.7, 1.5.0.1. ПописАл тестовых примеров. Пару оконных приложений, пару еще каких-то. Библиотеки поделал разные. Как разработчик библиотек мне бы такая функция была очень бы полезна. Может это и свист. Но язык мне очень понравился.

Практически (т.е. за бабки) я на ней не писал ни разу. Это верно.

> Игорь Шевченко © (31.08.05 14:34) [34]
> Igorek © (31.08.05 14:29) [32]
> Тебе кофейной гущи не выслать наложенным платежом ?

Высылай! :)
--
Мне на самом деле интересно, что может вызвать AV в .NET проекте.

Checked-exceptions, добро или зло? Найти похожие ветки