Прослушал тут курсы C#...

← →
pasha_golub © (2006-03-23 15:14) [120]

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

типо

procedure Check(ErrCode: integer);
begin
case ErrCode of
ERR_FILE_NOT_FOUND: raise EFileNotFound.Create("blablabla");
ERR_...
end;
end;

Соответственно вызов метода будет

Check(GetSizeOfSomeFile("path"));

Пример взят из той же самой Делфи, модуль DbTables.pas, где процедура Check выглядит как:

procedure Check(Status: DBIResult); begin if Status <> 0 then DbiError(Status); end;

← →
iZEN © (2006-03-23 15:16) [121]

>Игорь Шевченко © (23.03.06 14:11) [111]
>А использование более общего предка Throwable ? ;)
Тогда будет потеря информации об исключении. Это как в анегдоте:
- Петька, приборы!!!!
- 29!
- Что 29?!
- А что приборы?
(, где "Приборы" & "29" == Throwable).

← →
DiamondShark © (2006-03-23 15:21) [122]

> Я бы код возвратил.

Тогда макароны из if-ов получатся. От их написания и, тем более, чтения становится тоскливо.

← →
DiamondShark © (2006-03-23 15:31) [123]

А, чуть не забыл.

This material should be approached with an open mind, studied carefully, and criticaly considered.

;-)

← →
Игорь Шевченко © (2006-03-23 15:35) [124]

DiamondShark © (23.03.06 15:21) [122]

А так получаются макароны из try/catch - какая разница, только писать дольше.

← →
DiamondShark © (2006-03-23 16:20) [125]

> Игорь Шевченко © (23.03.06 15:35) [124]

В том-то и дело, что не получаются.

Эх... нет под рукой текста недавнего моего сокетно-файлово-одбсёвого проекта...

← →
Суслик © (2006-03-23 16:31) [126]

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

← →
Игорь Шевченко © (2006-03-23 16:33) [127]

DiamondShark © (23.03.06 16:20) [125]

А разве анализ разных exceptions не равноценен анализу разных кодов возврата ?

Или вы имеете в виду, что получается код вида

if Foo = SUCCESS then
if Bar = SUCCESS then
if FooBar = SUCCESS then
DoRealWork
else
Die
else
Die
else
Die

вместо

try
Foo;
Bar;
FooBar;
DoRealWork;
except
Die;
end;

?

← →
Игорь Шевченко © (2006-03-23 16:34) [128]

Суслик © (23.03.06 16:31) [126]

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

А я, собственно, пробовал...Не на java правда. Я свои суждения из опыта выношу, так ска-ать.

← →
DiamondShark © (2006-03-23 16:43) [129]

> Игорь Шевченко © (23.03.06 16:33) [127]

Примерно, что-то в этом роде, да.

← →
Суслик © (2006-03-23 16:45) [130]

> [128] Игорь Шевченко © (23.03.06 16:34)

а ты на ней, на java, попробуй.
Ты знаешь, действительно дисциплинирует.
Вот скажи, нет у тебя мечты, чтобы у тебя были дисциплинированные программисты? Наверное, есть. Ясный перец, что только checked expetion"ами их не дисциплинируешь. Но это тоже что-то. Конечно, можно сказать, что рубль дисциплинирует. Но ... тут спорить не буду. :)

Потом, не забывай, что java фреймвоковый язык, для которого разработана туча сред обитания. Одних серверов приложений сколько. В java также есть рефлексия. Как разработчику сервера тебе не плохо бы знать, какие исключения выбрасывает метод. Ясное дело, что runtime exception никто не запрещал возбуждать. А вот другие, явно возбуждаемые в методе ДОЛЖНЫ быть описаны в секции throws (иначе не скомпилиться). Т.е. по сути обсуждаемый механизм есть подписание контракта между тобой (разработчиком логики) и сервером приложений. Вот.

← →
Игорь Шевченко © (2006-03-23 17:03) [131]

Суслик © (23.03.06 16:45) [130]

Эх, молодость, молодость....

DiamondShark © (23.03.06 16:43) [129]

Это безусловно верно, код получается менее макаронным. В случае использования exception, как сигнализации об ошибке, после которой должна следовать естественная смерть (в рамках какого-то участка кода), я и сам так рекомендую делать. В случае же, когда тип исключения начинает определять логику программы (и таких примеров можно найти), например, как в [120], программу становится крайне неудобно отлаживать. Потому что при попытке выполнить в отладчике шаг на следующую строку, меня выбрасывает в то место, где произошло исключение.

> [131] Игорь Шевченко © (23.03.06 17:03)

Крайне не понятны Ваши слова про молодость. Неконсруктивно это.

В [130] упомянуты сервера приложений, коих масса. Есть ощущение, что их тоже молодые делают? :)

Игорь Шевченко © (23.03.06 16:33) [127]

if foo <> SUCCESS then die("foo") else
if bar <> SUCCESS then die("bar") else
.............
и т.д.

Будет по крайней мере понятно из-за кого случился die и для этого восе не обязательно, чтобы foo, bar и т.д. генерировали специфические типы exceptions или разные коды ошибок

> iZEN © (21.03.06 12:20) [44]
> >GrayFace © (21.03.06 11:12) [43]
> >Сколько ни программировал - ни разу "половины случаев"
> не встречал. >По-моему, самое частое исключение - это Access
> Violation.
> Ну и что, по-вашему, послужило причиной Access Violation?
> Скорее всего не знаете. А это рантайм-исключение (Unchecked),
> вызванное обращением к неразмеченной области памяти (скорее
> всего Null Pointer Exception). Но оно слишком общее, чтобы
> судить о контексте выполнения в работающей системе. Кстати,
> под него очень часто подпадают необработанные исключения,
> которые возникают в библиотечных методах — в тех самых
> "малозаметных узких местах". Вы их не видите, потому что
> не обрабатываете там, где следовало бы просто из-за недостатка
> информации о реальной сигнатуре метода (когда вызываемый
> метод бросает явное или неявное исключение). Исполняющая
> система Delphi ловит "наверху" всё, по определению, вот
> и выдаёт слишком общее сообщение об ошибке.

Поверьте, я знаю, что говорю.
Если учесть, что все библиотеки Windows не бросают исключений (в 99% случаев), не надо быть семи пядей во лбу, чтобы понять, что никаких "малозаметных узких мест" нету и причина в залазенье за границы масиива и т.п.
Я это к тому, что говорить о "узких местах" в половине случаев абсурдно, т.к. в половине случаев сторонние библиотеки вообще не используются.
А единственное, что не выдается "наверху" про AV - это класс исключения, если это наследник. Только наследники AV - это рекость, да и никто не мешает в Application.OnException вызывать обычный ShowException.

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

Прослушал тут курсы C#... Найти похожие ветки