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

← →
Igorek © (2005-08-31 14:50) [40]

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

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

← →
DiamondShark © (2005-08-31 14:57) [41]

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

Так значит тебе не составит труда привести пример и внятно рассказать, в чём состоит удобство.

← →
Kapusto (2005-08-31 15:26) [42]

Единственное, что напрягает в checked exception - это версионность библиотек. Вот тут при общении клиентского кода и библиотек либо приходится обходиться общим DomainException, и через InnerException передавать, что собственно случилось, либо получаем большую связанность между клиентским и библиотечным кодом...

Но имхо это небольшая плата за то, что я знаю сразу, что мне может высыпаться в конкретной точке, и это заставляет сразу продумывать стратегию обработки нештатных ситуаций... Другое дело, что если везде в коде идет catch(Exception e) {}, то такая обработка нафиг никому не нужна, лучше бы уж ее не было :)

← →
Суслик © (2005-08-31 16:11) [43]

> DiamondShark © (31.08.05 14:57) [41]

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

Ну давай пример (имена классов не помню, потому без имен классов, но идея понятна).

Есть некий класс, который я разрабатываю и который делает некие файловые операции. Файловые операции возбуждают исключения, которые кто-то обязан обработать.

У меня два варианта:
1. Обработать их самому внутри своего класса. При этом клиент класса не узнает о том, что эти исключения вообще были (если я, конечно, не возбуждю новое исключение).
2. Обязать клиента обрабатывать исключения.

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

Опять же повторю, что, как мне кажется, приемущества подхода java проявляются в относительно больших командах разработчиков. В этом случае большую часть работы за контролем итерфейса общения разных разработчиков берет на себя компилятор. Вернее он дает возможность одному разработчику более детально, чем просто имена классов, их методов и параметры, сообщить интерфейс к своему творению.

← →
Суслик © (2005-08-31 16:36) [44]

> [43] Суслик © (31.08.05 16:11)

Добавка.
При этом при разработке своего класса, если я пользуюсь классом, разработанным грамотным разработчиком, я не смогу пропустить обрабоку исключений (компилятор не даст). Я либо их обработаю, либо скажу что мои методы возбуждают эти исключения. Т.о. конечный клиент класса сможет разработать класс, который всегда делает что-то осознанное при возникновении всех возможных (RuntimeException не рассматриваем) исключительных ситуаций.

← →
Mystic © (2005-08-31 16:44) [45]

> то хорошим тоном было бы сообщить об этом тому, кто будет
> использовать мой код

Лично я редко нуждаюсь в такой информации.

> И вот думай - нужно тебе обрабатывать исключения того (третьего)
> класса или нет.

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

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

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

← →
Игорь Шевченко © (2005-08-31 16:48) [46]

Mystic © (31.08.05 16:44) [45]

> Лично я редко нуждаюсь в такой информации

> Я привык исходить из того, что исключения может вызвать
> любой метод :)

> Я и так обычно уверен, что в плане exception все правильно.

Успокаивает то, что Java не только для тебя написана :)

← →
Суслик © (2005-08-31 17:09) [47]

> [45] Mystic © (31.08.05 16:44)

Не зря, кстати, одна из главных книг по java "thinking in java" Эккеля именно так называет: в java надо думать именно javой. :)

← →
Mystic © (2005-08-31 17:29) [48]

Нет, я прекрасно понимаю, что в коде подобном этому

procedure CheckFail(WinConrol: TWinControl; const Msg: string); begin Raise ECheckFail(WinControl, Msg); end; procedure TSomeObject.Validate; var I: Integer; begin try for I := 0 to Validators.Count-1 do Validators[I].Check except on E: ECheckFail do begin ActiveControl := E.WinControl; MessageDlg(E.Message, mtError, [mbOk], 0); end; end; end;

в Java можно еще на этапе компиляции гарантировать, что метод CheckFail не вызовется случайно вне контекста метода TSomeObject.Validate, но большого облегчения труда программиста от этого я не вижу :)

а где он вообще вызывается?

Можно я скажу важную вещь?
Не для каждой библиотеки можно достать документацию, тем более провести декомпиляцию (как правило обфусцированного) кода, если библиотека закрытая.
Checked-exception"s в java избавляет от необходимости заглядывать в документацию на класс и тем более в его исходники - всё проверяется во время компиляции твоего кода, использующего тот сторонний класс без тестовых запусков.

> а где он вообще вызывается?

Validators[I].Check

ну и в методах, которые вызываются ними.

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