Здравствуйте, fionbio, Вы писали:

F>а) Научившись программировать на Lisp'е, можно стать асом C#/Java/C++/etc.
F>Программировать на мейнстриме будете с отвращением, но качественно. И смысл разных
F>design patterns и пр. хрени станет яснее, чем для авторов этих концепций Ещё подход -
F>использование Лиспа для прототипизирования.

Нет действительно у меня сложилось впечатление что многие "новейшие" концепции, как будто, бы первоначально обкатывались на Лиспе. Когда в CLOS появились :before :after и :around методы? До AspectJ или после?

И еще один вопрос возник. В Лиспе достаточно интересно реализован механизм обработки исключительных ситуаций. А Java/C#/C++, по сравнению с этим, мягко говоря, сильно ограниченны. С первого взгляда и IMHO

А есть ли другие языки с похожим на Лисп или альтернативными подходами к этому делу?

Здравствуйте, mishaa, Вы писали:

M>И еще один вопрос возник. В Лиспе достаточно интересно реализован механизм обработки исключительных ситуаций. А Java/C#/C++, по сравнению с этим, мягко говоря, сильно ограниченны. С первого взгляда и IMHO

А знаешь почему в мэйнстрим-языках так "хреново" с обработкой исключений? Я вот тоже задумался... Провел исследование. Ниже количество конструкций try/ххх в проектах:

* Rsdn.Editor - 10 (на 300+ Кб исходников)
* R#          -  8 (На 1+ Мб исходников)
* RSDN@Home   - 80 (На 2.3 Мб исходников)

Причем, что забавно в проектах Rsdn.Editor и R# почти все try/xxx — это try/finally или вообще отладочные куски кода.

Как ты думашь, чем при таких объемах могут не удовлетварить try/catch/finally?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, mishaa, Вы писали:

VD>А знаешь почему в мэйнстрим-языках так "хреново" с обработкой исключений? Я вот тоже задумался... Провел исследование. Ниже количество конструкций try/ххх в проектах:
[пропушено]]
VD>Как ты думашь, чем при таких объемах могут не удовлетварить try/catch/finally?

Хм.. если инстументом не пользуются может он неудобный?

А вот я посмотрел на реализацю Apache Ant

org.apache.tools.ant — 1042 (5585Кб) — неужто мало.

P.S. Если интересует, то считал я так:

     find . -exec grep " try {" \{\}\; | wc -l

Здравствуйте, mishaa, Вы писали:

VD>>А знаешь почему в мэйнстрим-языках так "хреново" с обработкой исключений? Я вот тоже задумался... Провел исследование. Ниже количество конструкций try/ххх в проектах:
M>[пропушено]]
VD>>Как ты думашь, чем при таких объемах могут не удовлетварить try/catch/finally?

M>Хм.. если инстументом не пользуются может он неудобный?

M>А вот я посмотрел на реализацю Apache Ant

M>org.apache.tools.ant — 1042 (5585Кб) — неужто мало.

M>P.S. Если интересует, то считал я так:
M>

     find . -exec grep " try {" \{\}\; | wc -l

Видишь ли, в Java большое количество try/catch может объясняться наличием спецификации исключений у методов -- задал кто-то в публичном интерфейсе спецификацию исключений от балды и все -- в реализациях этих методов нужно ставить try/catch для того, чтобы перехватывать исключения, не удовлетворяющие спецификации и транслировать их в какое-то специфицированное исключение. В C++ и, как я понимаю, в C# такой проблемы нет, поэтому try/catch можно использовать только там, где это физически необходимо и имеет смысл.

eao197 wrote:

> Видишь ли, в Java большое количество try/catch может объясняться
> наличием спецификации исключений у методов -- задал кто-то в публичном
> интерфейсе спецификацию исключений от балды и все -- в реализациях
> этих методов нужно ставить try/catch для того, чтобы перехватывать
> исключения, не удовлетворяющие спецификации и транслировать их в
> какое-то специфицированное исключение. В C++ и, как я понимаю, в C#
> такой проблемы нет

Явная спецификация исключений — это, ИМХО, большой плюс. Ее бы еще до
ума довести, например так:

void method1() throws Exception1 {...};
void method2() throws Exception2 wraps Exception1 {method1();}

То есть добавить еще и декларативную спецификацию оборачивания
исключений, ну и доработать try..catch для этого.

Только представьте:

struct SomeStruct
{
    SomeStruct(const SomeStruct &other) throw(blah_blah_exception) {};
};

struct container
{
    void swap(...) throw(std::bad_alloc, std::runtime_error wraps *) {};
}

И потом контролировать это все на этапе компиляции.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Cyberax,

C> Явная спецификация исключений — это, ИМХО, большой плюс.

Как я понимаю, вопрос достаточно спорный... Это без труда обнаруживается простым запросом
java checked exceptions, даже не содержащим ничего кроме самого
термина:

Bruce Eckel's MindView, Inc: Does Java need Checked Exceptions?

Checked exceptions seem like a really good idea at first. But it's all based on our unchallenged
assumption that static type checking detects your problems and is always best. Java is the first
language (that I know of) that uses checked exceptions and is thus the first experiment. However,
the kind of code you must write around these things and the common phenomenon of "swallowed"
exceptions begins to suggest there's a problem. In Python, exceptions are unchecked, and you can
catch them and do something if you want, but you aren't forced. And it seems to work just fine.

Java's checked exceptions were a <br />
mistake

Checked exceptions are pretty much disastrous for the connecting parts of an application's
architecture however. These middle-level APIs don't need or generally want to know about
the specific types of failure that might occur at lower levels, and are too general purpose
to be able to adequately respond to the exceptional conditions that might occur.

The Trouble with Checked Exceptions

Anders Hejlsberg: I see two big issues with checked exceptions: scalability and versionability.

Exceptional Java by Alan Griffiths

We'll be examining more of the problems they described in the rest of this article — this section
deals only with those that bear directly on the above theory (that checked exceptions should be
used for everything that isn't a programming error). Before proceeding, I want to make it clear
that this development group isn't the only one to experience these problems. They are in good
company — as I confirmed at the ACCU Spring conference last year. It seems that this theory
doesn't work in practice.

The relevant problems described fall into three categories:
Breaking encapsulation
<...>
Loss of information
<...>
Information overload
<...>

Avoiding Checked Exceptions

When calling a method that throws a checked exception, you have a few options. You can catch the
exception and handle it yourself; however, this is not always possible. You can declare that you
also throw the checked exception, but this can lead to a proliferation of throws declarations as
exceptions need to propagate farther and farther up the stack. Many exceptions are best handled
at the top level of the stack, or even outside of the stack in an UncaughtExceptionHandler, and
it doesn't take many checked exceptions before this process can become untenable.

И т.д., и т.п.

Павел Кузнецов wrote:

> C> Явная спецификация исключений — это, ИМХО, большой плюс.
> Как я понимаю, вопрос достаточно спорный...

Так поэтому и "ИМХО".

> Это без труда обнаруживается простым запросом

Однако справедливые возражения того же Гослинга или Гриффита
(http://octopull.demon.co.uk/java/ExceptionalJava.html) почему-то не
находятся сразу же.

Причем несложно заметить, что основные возражения о exception'ах идут от
любителей динамических языков, с их идеологией "нафиг нам системы
безопасности не нужны — у нас есть юнит-тесты".

Хотя доработать систему исключений не мешало бы, идей есть достаточно
много. Например добавить декларативный exceptions-chaining, try..catch с
поддержкой вложенных исключений, трансформаторы исключений и т.п.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:


C>Хотя доработать систему исключений не мешало бы, идей есть достаточно
C>много. Например добавить декларативный exceptions-chaining, try..catch с
C>поддержкой вложенных исключений, трансформаторы исключений и т.п.

А можете по подробенее рассказать про exceptions-chaining и транформаторы исключений?

Кстати в Лиспе ничем таким не пахнет (по умолчанию ессно), там exceptions's реализован как сигнал, уходящий вверх по стеку. Сигнал в принципе может быть любым, например аналогичный механизм испльзуется и для warning'ов.

А главная фича, так это определение различных restart case'ов. Нигде кроме Лиспа я про подобное не слышал.

mishaa wrote:

> C>Хотя доработать систему исключений не мешало бы, идей есть достаточно
> C>много. Например добавить декларативный exceptions-chaining,
> try..catch с
> C>поддержкой вложенных исключений, трансформаторы исключений и т.п.
> А можете по подробенее рассказать про exceptions-chaining и
> транформаторы исключений?

С chaining'ом все просто — одно исключение "вкладывается" в другое, то
есть получается цепочка исключений. Типа SQLException был вызван
NullPointerException'ом, который был вызван OutOfBoundsException'ом. С
jdk1.4 это стандартная фича.

Трансформаторы позволяют декларативно объявлять, что для некоторых
методов/классов/пакетов исключения одного типа будут преобразованы в
исключения другого типа (в том числе можно и в unchecked-исключения).
Такое пока можно сделать с помощью AOP.

> Кстати в Лиспе ничем таким не пахнет (по умолчанию ессно), там
> exceptions's реализован как сигнал, уходящий вверх по стеку. Сигнал в
> принципе может быть любым, например аналогичный механизм испльзуется и
> для warning'ов.
> А главная фича, так это определение различных restart case'ов. Нигде
> кроме Лиспа я про подобное не слышал.

А никому они и не нужны, по большему счету.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

>> C> Явная спецификация исключений — это, ИМХО, большой плюс.
>> Как я понимаю, вопрос достаточно спорный...

C>Причем несложно заметить, что основные возражения о exception'ах идут от
C>любителей динамических языков, с их идеологией "нафиг нам системы
C>безопасности не нужны — у нас есть юнит-тесты".

Я не являюсь сторонником динамических языков, но меня в Java спецификация исключений напрягала. Как и отсутствие таковой (то, что сейчас есть не зря рекомендуют не использовать) в C++. В Java плохо то, что кто-то из каких-то своих соображений пропишет в спецификации какое-то исключение (типа NullPointerException) и все, труба. Начинаешь реализовывать интерфейс и вынужден все исключения либо подавлять, либо инкапсулировать. Хотя пользы от этого никакой. Имхо, самый лучший выход был бы просто писать throws Exception.

А в C++, напротив, нельзя понять, функция:

void f();

будет генерировать исключения или нет. Конечно, можно перестраховаться и все неизвестные функции в try/catch обрамлять (особенно в деструкторах). Но ведь это overhead не слабый получается.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Cyberax, Вы писали:

...

E>будет генерировать исключения или нет. Конечно, можно перестраховаться и все неизвестные функции в try/catch обрамлять (особенно в деструкторах). Но ведь это overhead не слабый получается.

синтаксический?

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Cyberax, Вы писали:


E>Я не являюсь сторонником динамических языков, но меня в Java спецификация исключений напрягала. Как и отсутствие таковой (то, что сейчас есть не зря рекомендуют не использовать) в C++. В Java плохо то, что кто-то из каких-то своих соображений пропишет в спецификации какое-то исключение (типа NullPointerException) и все, труба.

Ну против лома нет приема, если код плохо написан, то там не только с исключениями проблема. Ну а выкидывать низкоуровневый а ля NullPointerException вобше IMHO маразм. Зачем вобше Exception'ы нужны — чтобы их кооректоно обрабатывать можно было, а понять че да как и почему NullPointer, особено если он не сразу а на уровня два вверх уходит, и уж корректно обработать его невозможно.

E>А в C++, напротив, нельзя понять, функция:
E>

E>void f();
E>

E>будет генерировать исключения или нет. Конечно, можно перестраховаться и все неизвестные функции в try/catch обрамлять (особенно в деструкторах). Но ведь это overhead не слабый получается.

Тем не менее C#-цы вроде не жалуются, а просто почти не используют try-catch, и утверждают что так и надо. интересно вобше с Exceptinos получается вроде и без них никак, но в тоже время и не переборшить надо. Есть интересно какие-нибудь Exception usage patterns ну или Style guidelines?

mishaa wrote:

> Тем не менее C#-цы вроде не жалуются, а просто почти не используют
> try-catch, и утверждают что так и надо. интересно вобше с Exceptinos
> получается вроде и без них никак, но в тоже время и не переборшить
> надо. Есть интересно какие-нибудь Exception usage patterns ну или
> Style guidelines?

Жалуются, кстати, — те кто перешел на С# из Java. Где-то находил пост от
Cameron Purdy на TheServerSide.com, что их до того это напрягло, что они
стали использовать third-party тулзу для отслеживания обработки
исключений в C#.

--
С уважением,
Alex Besogonov (alexy@izh.com)

eao197 wrote:

> C>Причем несложно заметить, что основные возражения о exception'ах
> идут от
> C>любителей динамических языков, с их идеологией "нафиг нам системы
> C>безопасности не нужны — у нас есть юнит-тесты".
> Я не являюсь сторонником динамических языков, но меня в Java
> спецификация исключений напрягала.

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

> Как и отсутствие таковой (то, что сейчас есть не зря рекомендуют не
> использовать) в C++. В Java плохо то, что кто-то из каких-то своих
> соображений пропишет в спецификации какое-то исключение (типа
> NullPointerException) и все, труба.

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

> Начинаешь реализовывать интерфейс и вынужден все исключения либо
> подавлять, либо инкапсулировать. Хотя пользы от этого никакой. Имхо,
> самый лучший выход был бы просто писать throws Exception.

Вот с этим как-то надо бороться. Методы есть, но ими серьезно никто не
занимается. А зря....

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Это демонстрация тезиса: "Любой инструмент может быть использован
C>неправильно". Если правильно использовать исключения, то они могут
C>помогать. Все как с типами.

>> Начинаешь реализовывать интерфейс и вынужден все исключения либо
>> подавлять, либо инкапсулировать. Хотя пользы от этого никакой. Имхо,
>> самый лучший выход был бы просто писать throws Exception.

C>Вот с этим как-то надо бороться. Методы есть, но ими серьезно никто не
C>занимается. А зря....

Вот собственно об этом я и говорил. Спецификация исключений, имхо, в теории полезная штука. Но вот в C++ и Java она реализована, имхо, неудачно.

eao197 wrote:

> C>Вот с этим как-то надо бороться. Методы есть, но ими серьезно никто не
> C>занимается. А зря....
> Вот собственно об этом я и говорил. Спецификация исключений, имхо, в
> теории полезная штука. Но вот в C++ и Java она реализована, имхо,
> неудачно.

В С++ мне жутко нравится механизм nothrow. Вот скрестить бы его с Java....

Попробовать что ли написать proposal?

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:


C>В С++ мне жутко нравится механизм nothrow. Вот скрестить бы его с Java....

nothrow — это Вы про __declspec

А зачем он в Java? Указать что и unchecked exeptions не проходят? Дык, а толку то. Может в C#-пе будет полезен.

mishaa wrote:

> C>В С++ мне жутко нравится механизм nothrow. Вот скрестить бы его с
> Java....
> nothrow — это Вы про __declspec
> <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_langref_nothrow.asp&gt;
>

Это я про "throw()" — обозначение того, что функция не будет кидать
никакие исключения.

> А зачем он в Java? Указать что и unchecked exeptions не проходят? Дык,
> а толку то. Может в C#-пе будет полезен.

В Яве/C# исключение может вылететь в любой момент (какой-нибудь
OutOfMemory), а в С++ можно гарантировать, что функции не кинут исключения.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Это я про "throw()" — обозначение того, что функция не будет кидать
C>никакие исключения.

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

try
    {
        <какой-то код>
    }
catch( ... )
    {
        unexpected(); // Т.е. throw bad_exception();
    }

Причем, кажется в boost и в mozilla, я встречал достаточно понятные и разумные обоснования по поводу того, что throw(), как и throw(something) лучше не использовать.

>> А зачем он в Java? Указать что и unchecked exeptions не проходят? Дык,
>> а толку то. Может в C#-пе будет полезен.

C>В Яве/C# исключение может вылететь в любой момент (какой-нибудь
C>OutOfMemory), а в С++ можно гарантировать, что функции не кинут исключения.

Это как?

eao197 wrote:

> C>Это я про "throw()" — обозначение того, что функция не будет кидать
> C>никакие исключения.
> Насколько я знаю, компиляторы не ругаются, если в функциях со
> спецификатором throw() вызываются функции со спецификацией исключений
> или вообще без спецификации исключений (и поэтому, потенциально,
> могущие порождать исключения).

Вообще-то, по пункту 15.4.4 компилятор должен ругаться на такое.

VC++ выводит предупреждение в этом случае.

> Все, что делает throw(), это, образно говоря:
>
>try
> {
> <какой-то код>
> }
>catch( ... )
> {
> unexpected(); // Т.е. throw bad_exception();
> }
>
>
Это как бы и есть гарантия того, что мой код не получит исключением в лоб.

> Причем, кажется в boost и в mozilla, я встречал достаточно понятные и
> разумные обоснования по поводу того, что throw(), как и
> throw(something) лучше не использовать.

Да, так как некоторые тупые компиляторы действительно генерируют такой
код во всех throw()-функциях. На нормальных компиляторах — можно.

>>> А зачем он в Java? Указать что и unchecked exeptions не проходят? Дык,
>>> а толку то. Может в C#-пе будет полезен.
> C>В Яве/C# исключение может вылететь в любой момент (какой-нибудь
> C>OutOfMemory), а в С++ можно гарантировать, что функции не кинут
> исключения.
> Это как?

По JLS (Java Language Specification) исключение может вылететь в любой
момент (наприме, VirtualMachineError).

--
С уважением,
Alex Besogonov (alexy@izh.com)