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

← →
iZEN © (2006-03-20 22:21) [40]

>Ломброзо © (20.03.06 20:43) [32]
>дадад
>public void OpenFile(String fileName)
> throws InvalidPathException,
> FileNotExistsException,
> FileIsLockedException,
> AccessDeniedException,
> IOException,
> HDDNotFoundException,
> OSException...
>{
>
>}
>
>и на всё это хозяйство надо повесить по кэтчу, что под силу только представителям педантичной нации типа ипонцев.

Несовсем.
Достаточно только те, которые не обрабатываются внутри этого метода.

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

>Прочих мало интесует, почему не окрывается файл. Не открылся - ну и хрен с ним.
Бросайте их общего предка.

Грамотный дизайн кода, как всегда, решает.

← →
Карелин Артем © (2006-03-21 05:41) [41]

> Piter © (20.03.06 22:01) [39]

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

← →
Тульский © (2006-03-21 10:47) [42]

> Например любую прогу, написанную на C# легко можно вскрыть
> на исх. коды например с помощью программы Рефлектор... т.
> е. пишем программу, компилируем, запускаем Рефлектор (ищется
> в инете легко), открываем через нее exe, оп ля, и все как
> на ладони.. :) Причем читается на любой язык, т.е. написали
> на C#, а коды можно читать как на BASIC.#, так и для Delphi.
> Net, и ещё для 2х языков...

Так это же замечательно!

← →
GrayFace © (2006-03-21 11:12) [43]

> iZEN © (20.03.06 21:37) [37]
> Необработанное исключение (всегда Unchecked Exception) в
> Delphi приводит к системному сообщению и/или к остановке
> выполнения программы. И это встречается очень часто. В половине
> случаев такое положение связано с неучтённой семантикой
> вызова библиотечного метода (забывчивость программиста,
> недостаточная документированность вызываемого кода и другие
> мантры, всё - действие ЧЕЛОВЕЧЕСКОГО_ФАКТОРА).

Сколько ни программировал - ни разу "половины случаев" не встречал. По-моему, самое частое исключение - это Access Violation.

← →
iZEN © (2006-03-21 12:20) [44]

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

В отладочном режиме, когда среда следит за такими исключениями, всё это можно проследить. Но всегда во время работы приложения. Что вы будете делать, когда приложение уже установлено на местах? Советовать пользователю: "не пользоваться определённой кнопкой, так как это может привести к непредсказуемым результатам с Access Violation"? И, может быть, "отозвать" приложение на повторную отладку и доводку? И снова проводить тесты качества...

Увы, в Delphi и C# это — единственный путь подтверждения корректности программы.

Я не говорю, что проверка компилятора на этапе сборки есть альтернатива, я говорю, что Checked Exception"s являются дополнительной проверкой корректности, "работающей" без необходимости запуска приложения на выполнение. Такой же важной составляющей надёжного ПО, что и первая сигнальная система на основе Uncheked Exception"s.

← →
Игорь Шевченко © (2006-03-21 12:28) [45]

> В отладочном режиме, когда среда следит за такими исключениями,
> всё это можно проследить. Но всегда во время работы приложения.
> Что вы будете делать, когда приложение уже установлено
> на местах?

А что, тестирование уже отменили ?

← →
Карелин Артем © (2006-03-21 12:58) [46]

> iZEN © (21.03.06 12:20) [44]

А что, Null pointer exception в яве проявляется реже чем AV??

← →
KSergey © (2006-03-21 16:07) [47]

Я, вероятно, не очень в курсе, но такое навязчивое впчатление, что вы говорите про С++.
Так может все дело в том, что в C++ (самом языке) нет декларированного общего предка для класса исключений? От того и нужны все эти пляски с чекалкой?
В дельфи я всегда могу написать

begin try ... except Exception e ... end; end.

и какой тут чекер что проверит? Очевидно, что кидаются только Exception... от того, видимо, просто отпал необходимость этих чеканий на этапе компиляции?

← →
Sandman25 © (2006-03-21 17:01) [48]

Например:

public void Login(...) throws WrongLoginParamsException, UserIsBlockedException, IPAccessDeniedException...

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

← →
Petr V. Abramov © (2006-03-21 17:06) [49]

> Sandman25 © (21.03.06 17:01) [48]
А кто мешает анализировать на основе класса исклчения?
или поподробней, если не сложно... :)

← →
pasha_golub © (2006-03-21 17:12) [50]

Нифига не могу понять суть checked exceptions. Вернее не суть, а "высшую суть", их так сказать божественное начало. Для чего они нам спущены были? Я с успехом во время ран-тайма все ловлю.

> Что вы будете делать, когда приложение уже установлено на
> местах?

EurekaLog.com forever !!! С помощью этой ляли такие "висяки" находил, шо страх и ужос. Под висяками я понимаю, как раз эти пресловутые, AV.

← →
Sandman25 © (2006-03-21 17:16) [51]

Petr V. Abramov © (21.03.06 17:06) [49]

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

← →
Sandman25 © (2006-03-21 17:18) [52]

pasha_golub © (21.03.06 17:12) [50]

Я с успехом во время ран-тайма все ловлю.

Ловите на здоровье. Потом где-то добавится новый Exception, где-то уберется старый, и Вам придется ручками бегать по модулям и проверять, чего и где. На java же будет выдан compile-time error.

← →
Petr V. Abramov © (2006-03-21 17:20) [53]

> Sandman25 © (21.03.06 17:16) [51]
Ну это-то идея понятная ( а значит, хорошая :)
Но причем здесь обязательная обработка-то? Может, меня устраивает стандартная реакция на UserIsBlockedException

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

> Ловите на здоровье. Потом где-то добавится новый Exception,
> где-то уберется старый, и Вам придется ручками бегать по
> модулям и проверять, чего и где. На java же будет выдан
> compile-time error

Это конечно все хорошо. Но Exception это вроде исключительная ситуация, поэтому народ в моем лице не совсем понимает, зачем ее отлавливать на уровне компиляции...
Пример бы разумный, где бы такое могло с успехом пригодиться, не помешал бы.

← →
Sandman25 © (2006-03-21 17:25) [55]

Petr V. Abramov © (21.03.06 17:20) [53]

Если устраивает, так и напишите в своем методе throws UserIsBlockedException, чтобы те, кто использует Ваш метод знали, что UserIsBlockedException Вы не обрабатываете, а передаете "выше".

← →
Petr V. Abramov © (2006-03-21 17:29) [56]

> Sandman25 © (21.03.06 17:25) [55]
То есть идея в том, что если в сигнатуре public void Login(...) добавится новый exception, который "throws", то поплывут все методы, которые Login используют, и, хочешь, не хочешь, придется задуматься, "устраивает" стандартное или нет?

← →
Sandman25 © (2006-03-21 17:34) [57]

Игорь Шевченко © (21.03.06 17:24) [54]

Но Exception это вроде исключительная ситуация, поэтому народ в моем лице не совсем понимает, зачем ее отлавливать на уровне компиляции...

Чтобы убедиться, что ничего не пропустили. Либо перехватываете, либо говорите всему миру, что не перехватываете и пускай они сами разбираются :) Никаких недомолвок и неактуальных документаций. Обычно проблемы в работе ПО связаны как раз с исключительными ситуациями.

← →
Sandman25 © (2006-03-21 17:35) [58]

Petr V. Abramov © (21.03.06 17:29) [56]

То есть идея в том, что если в сигнатуре public void Login(...) добавится новый exception, который "throws", то поплывут все методы, которые Login используют, и, хочешь, не хочешь, придется задуматься, "устраивает" стандартное или нет?

Верно. Не будет ситуации, что метод изменили, а клиент об этом даже не знает, и поэтому некорректно работает.

← →
Sandman25 © (2006-03-21 17:38) [59]

Petr V. Abramov © (21.03.06 17:29) [56]

Конечно, елси клиент throws Thorwable, как тут писали некоторые, то толку от идеи никакой, только вред один. Ну так это проблемы тех, кто так пишет.
try
...
except
end
тоже не слишком полезен :)

← →
Petr V. Abramov © (2006-03-21 17:39) [60]

> Sandman25 © (21.03.06 17:35) [58]
Сколько возможностей для мелкого хулиганства в большом проекте :)
Добавил в throws какого-нить очень популярного, но изнутри запутанного метода, и в отпуск на недельку :)
Но что-то в этой идее есть

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

Sandman25 © (21.03.06 17:34) [57]

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

Я извиняюсь, но из кода

> public void Login(...) throws WrongLoginParamsException,
> UserIsBlockedException, IPAccessDeniedException

следует, что как раз наоборот, я говорю всему миру, что я могу выдавать наружу exceptions определенного типа. А о перехвате в объявлении вроде не упоминается. Или я что-то не так понял ?

Sandman25 © (21.03.06 17:38) [59]

> try
> ...
> except
> end
> тоже не слишком полезен :)

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

← →
Sandman25 © (2006-03-21 17:56) [62]

Я смотрю, мне надо было не лениться и сразу написать всю цепочку :(

Допустим есть стандартный класс

public class TStandardDataBase..{
public void Login(...) throws WrongLoginParamsException, UserIsBlockedException, IPAccessDeniedException;
}

и собственный класс
public TMyClass ..{
private TStandardDataBase myDataBase;
public void myLogin throws UserIsBlockedException, IPAccessDeniedException{
...
try
{
myDataBase.Login;
}
catch (WrongLoginParamsException e)
{
logger.WriteCriticalError(e);
System.exit(-1);
}
}
}

Таким образом, хотя Login и генерирует WrongLoginParamsException, обрабатывать его в коде, который вызывает myLogin(), не надо:

try
{
myClass(..)
}
catch (UserIsBlockedException e)
{
...
}
catch (IPAccessDeniedException e)
{
...
}

← →
Sandman25 © (2006-03-21 17:58) [63]

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

← →
KSergey © (2006-03-21 18:01) [64]

> Sandman25 © (21.03.06 17:25) [55]
> Если устраивает, так и напишите в своем методе throws UserIsBlockedException,
> чтобы те, кто использует Ваш метод знали, что UserIsBlockedException
> Вы не обрабатываете, а передаете "выше".

Во, видел я такой код (с++).
Что мне из него стало совершенно не ясно:
положим, я в своем новом мега супер методе вызываю 10 других методов 5 объектов. Те, в свою очередь, еще чео-то тама унутрях себя вызывают. Все, как водится, норовят кинуть исключения всякие. Теперь получается так: я должен оббежать все 10 методов - и выяснить: а какого же они могут выкинуть фердебобеля? Ага, до фига всего. Так, значит или крутить обработку тут, или все оту фигню прописывать у себя в сигнатуре.... Короче капец полный получается...

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

← →
Игорь Шевченко © (2006-03-21 18:10) [65]

> Тайный смысл пока так и не понял....

Присоединяюсь к предыдущему оратору.

> Допустим есть стандартный класс
>
> public class TStandardDataBase..{
> public void Login(...) throws WrongLoginParamsException,
> UserIsBlockedException, IPAccessDeniedException;
> }
>
> и собственный класс
> public TMyClass ..{
> private TStandardDataBase myDataBase;
> public void myLogin throws UserIsBlockedException, IPAccessDeniedException{
> ...
> try
> {
> myDataBase.Login;
> }
> catch (WrongLoginParamsException e)
> {
> logger.WriteCriticalError(e);
> System.exit(-1);
> }
> }
> }
>
> Таким образом, хотя Login и генерирует WrongLoginParamsException,
> обрабатывать его в коде, который вызывает myLogin(), не
> надо:

Я извиняюсь за оверквотинг, но если из-за кривости рук программиста, написавшего Login(...) из него выскочит какой-то другой Exception из неуказанных в сигнатуре метода, то что произойдет и как мне поможет компилятор ?

← →
DiamondShark © (2006-03-21 18:16) [66]

Кстати, а что произойдёт, если метод всё-таки выбросит недекларированное исключение?
ну вот например метод, вроде такого

int MyCrazzyMethod(int a, int b)
{
return a/b;
}

будет вызван с параметрами (1, 0)?

Вы почему throws ZerroDivide нигде не пишете?

← →
DiamondShark © (2006-03-21 18:17) [67]

> Игорь Шевченко © (21.03.06 18:10) [65]

Телепатия :)

← →
DiamondShark © (2006-03-21 18:22) [68]

> вот эти копирования сигнатур шибко напрягают, признаюсь

рано или поздно все выучат заклинание "throws Thowable" и забудут про Фундамент(тм) как про страшный сон
:)

>>DiamondShark © (21.03.06 18:16) [66]

А операция деления throws ZeroDivideException или как-там его, насколько я понимаю. Посему, либо обрабатываем сами, либо указываем в заголовке, чтоб оставляем на откуп вызвавшему.

чтоб оставляем -> что оставляем

Lamer@fools.ua © (21.03.06 18:23) [69]

> Посему, либо обрабатываем сами

А эта...зачем тогда наружу вообще что-либо выбрасывать, можно самому обрабатывать. Ну и наружу код возврата, как в старые добрые времена.

> либо указываем в заголовке, чтоб оставляем на откуп вызвавшему

То есть, каждый метод, кроме a + b должен в заголовке писать Throws EAccessViolation или как там он в Java называется ? :)

> Lamer@fools.ua © (21.03.06 18:23) [69]

Для всех операций есть список декларированных исключений?

Я почему спрашиваю. Интересно, что будет, если произойдёт недекларированное исключение.
Конечно, если ВСЕ операции считаются методами с декларированными исключениями, то такой ситуации теоретически быть не может.

Но интересно же... :)

> То есть, каждый метод, кроме a + b должен в заголовке писать
> Throws EAccessViolation или как там он в Java называется
> ? :)

Гыгы. Блин. По хорошему можно сразу весь список доступных эксепшнов.

>>Игорь Шевченко © (21.03.06 18:28) [71]

>То есть, каждый метод, кроме a + b должен в заголовке писать Throws EAccessViolation или как там он в Java называется ? :)
Я совсем не спец по Java, но поскольку он весьма похож на .NET, рискну предположить, что как и в .NET, пользовательский код не может бросить исключения типа AccessViolationException. Правда, в .net (точнее в c#) есть unsafe код. В нём такое исключение может произойти.

>>DiamondShark © (21.03.06 18:41) [72]

Опять же, я совсем не спец по Java, но поскольку он весьма похож на .NET, подозреваю, что как и в .NET все операции — это просто перегруженные операторы у классов и структур. Соотвественно для них действуют те же правила о "throws".

З.Ы.
Что меня самого интересует, так это исключение NullReferenceException (так в .NET называется, как в Java — не знаю). От него особо не застрахуешься, когда есть конструкции вида:
a.b[i].c
А вдруг a, b или b[i] равны null?

> Что меня самого интересует, так это исключение NullReferenceException
> (так в .NET называется, как в Java — не знаю). От него особо
> не застрахуешься, когда есть конструкции вида:
> a.b[i].c
> А вдруг a, b или b[i] равны null?

Во, во... Именно это и имелось ввиду.

Lamer@fools.ua © (21.03.06 18:57) [74]

> Я совсем не спец по Java, но поскольку он весьма похож на
> .NET, рискну предположить, что как и в .NET, пользовательский
> код не может бросить исключения типа AccessViolationException.
> Правда, в .net (точнее в c#) есть unsafe код. В нём такое
> исключение может произойти.

В .Net код очень даже может выбросить Exception, которого совсем не ждешь. Причем, хотя ноги у него растут от NullReference, наверное из-за таких вот throws-конструкций окончательный Exception получается совсем другой (но, опять же, неожиданный). В опытах с D2005 такие примеры довольно легко получаются, достаточно требуемую сборку расположить вне поля видимости :)

> Игорь Шевченко © (21.03.06 21:05) [76]
> В .Net код очень даже может выбросить Exception, которого совсем не ждешь.
Я так понял, что если какая-то неожиданная (даже самим автором метода) фигня вылезет, но она не указана в throws, то все пойдет, как в старом добром Delphi32

> [77]
Точнее, конечно, сказать, предположил из соображений здравого смысла :)))

>Игорь Шевченко © (21.03.06 18:10) [65]
> Я извиняюсь за оверквотинг, но если из-за кривости рук программиста, написавшего Login(...) из него выскочит какой-то другой Exception из неуказанных в сигнатуре метода, то что произойдет и как мне поможет компилятор ?

>DiamondShark © (21.03.06 18:16) [66]
>Кстати, а что произойдёт, если метод всё-таки выбросит недекларированное исключение?
>ну вот например метод, вроде такого
>int MyCrazzyMethod(int a, int b)
>{
> return a/b;
>}
>будет вызван с параметрами (1, 0)?
>Вы почему throws ZerroDivide нигде не пишете?

Если вам так важно объявить о том, что код метода потенциально может произвести деление на ноль и бросить исключение, то можете совершенно спокойно объявить класс ZerroDivide наследником Exception (но только не наследником RuntimeException!), в теле метода перехватить runtime-исключение ArithmeticException, в блоке catch бросить важное вам исключение:
public class ZerroDivide extends Exception {}
public class ArithmeticTest { public static int MyCrazzyMethod(int a, int b) throws ZerroDivide { try { return a / b; } catch (ArithmeticException ex) { throw new ZerroDivide(); } } }
и люди, которые будут использовать ваш код без исходников и документации, будут счастливы, так как с помощью без всяких запусков и тестов, только с помощью сообщений компилятора знают, где разложены грабли и попытаются на них не наступить уже в своём коде!

Недекларируемые исключения, как правило, относятся к подклассу RuntimeException, такие исключения в большинстве динамических языков есть непроверяемые исключения (unchecked exceptions). То же самое — подклассы Access Violation (хотя это я бы уже отнёс к Error, серьёзной ошибке времени выполнения), Null Pointer Exception, Null Reference Exception и другие.

Например, в иерархии наследования классов Java чётко прослеживаются три линии исключительных ситуаций:
* критические ошибки (errors), которые нельзя поймать в прикладном коде, они также непроверяемые (например, ошибка исчерпания свободной памяти: Throwable - Error - OutOfMemoryError) — на этапе выполнения аварийный останов системы исполнения;
* проверяемые исключения (Throwable - Exception - все потомки кроме RuntimeException) — компилятор отслеживает семантику использования уже на стадии компиляции;
* непроверяемые исключения (Throwable - Exception - RuntimeException - все потомки), которые можно поймать на этапе выполнения, но необязательно объявлять об их бросании, так как компилятор совсем не проверяет их семантику использования, — всё узнаётся только на этапе выполнения.
Здесь: Throwable — предок всех классов исключительных ситуаций и ошибок выполнения.

По-моему, программисты с ума бы сошли, если бы все исключения были бы проверяемыми. Представьте: в каждом методе писать список throws и/или вручную следить за целостностью ссылок (!= null), за ошибками выхода за границы массива, за ошибки приведения к типу (dynamic class casting), за переполнением при делении на ноль и т.д. Физически нецелесообразно объявлять все исключения проверяемыми. Да это и не нужно, если не надо расставлять акценты для защиты кода.

Все классы-наследники java.lang.RuntimeException, таким образом, являются полными аналогами Exception в Delphi и C#.

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