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

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

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

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

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

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

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.

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.

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

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
<...>

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.

void f();

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

class    E {};

void f() throw( E )
{
    throw E();
}

void a() throw()
{
    f();
}

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

throw.cpp

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

throw.cpp
throw.cpp(3) : warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)

Thank you for testing your code with Comeau C/C++!
Tell others about http://www.comeaucomputing.com/tryitout ! 

Your Comeau C/C++ test results are as follows: 

Comeau C/C++ 4.3.3 (Aug  6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing.  All rights reserved.
MODE:strict errors C++

In strict mode, with -tused, Compile succeeded (but remember, the Comeau online compiler does not link).

 e>> void f();
 e>>

void f();
void h() throw( std::exception );

void g() nothrow
    {
        f();
        
        try
            {
                h();
            }
        catch( const std::exception & x )
            {
            }
    }

void f(); // throw()
void g(); // throw(MyException)

template< class E >
void throw_(); // always throws E

void f() NOTHROW;

template< class E >
void throw_() NORETURN;

interface I
{
   void f();
};

class C1 : I
{
   void f() // или что надо написать, чтоб реализовать I::f...
   {
     throw new Exception1();
   }
};

class C2 : I
{
   void f() // или что надо написать, чтоб реализовать I::f...
   {
     throw new Exception2();
   }
};

void g( I i )
{
   i.f(); // И какой список здесь должен генерировать компилятор?..
          // Какие сборки будут подгружены, кроме данной, и от какого класса придет I — :xz:
}

A programming language can't solve all the problems. A language can't
guarantee that no matter how screwed up the environment gets the program
will survive. But anything the language can do to increase the
probability that programs will be reasonably graceful under fire is a
good thing. For example, just making people at least willfully ignore
return codes helps. In Java you can ignore exceptions, but you have to
willfully do it. You can't accidentally say, "I don't care." You have to
explicitly say, "I don't care."

void *__cdecl operator new(size_t size) _THROW1(_STD bad_alloc)
{       // try to allocate size bytes
        void *p;
        while ((p = malloc(size)) == 0)
                if (_callnewh(size) == 0)
                        _STD _Nomemory();
        return (p);
}
...
_CRTIMP2 void __cdecl _Nomemory()
    {    // report out of memory
    static const _XSTD bad_alloc nomem;
    _RAISE(nomem);
    }
...

try
{
  DoWhateverYouWant();
}
catch (Exception ex)
{
}

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

void    do_something( const char * p ) {
    if( !p )
        throw std::invalid_argument( "do_something: p == 0!" );
    ...
}

do_something( find_user_group_name( user_name, user_security_data ) );

const char * group_name = find_user_group_name( user_name, user_security_data );
if( group_name )
    do_something( group_name )
else
    ...

public string FormatCurrencyLocalized(decimal amount)
{
    if (Resources != null)
        return String.Format(Resources.GetString("CurrencyFormat"), amount);
        
    return String.Format("{0}:C", amount);
}

public string FormatCurrencyLocalized(decimal amount)
{
        try { return Resources.GetString("CurrencyFormat") + amount.ToString("C");}
        catch { return amount.ToString("C"); }
}

using System;
using System.Windows.Forms;
using System.Drawing;

public partial class Form1 : Form
{
    public Form1()
    {
        FlowLayoutPanel layout = new FlowLayoutPanel();
        Controls.Add(layout);
        Button button1 = new Button();
        button1.Text = "Нажми меня!";
        button1.AutoSize = true;
        Button button2 = new Button();
        button2.Text = "Не жми меня!";
        button2.Font = new Font(button2.Font, FontStyle.Bold);
        button2.AutoSize = true;
        layout.Controls.Add(button1);
        layout.Controls.Add(button2);
        button1.Click += delegate { MessageBox.Show(this, "Усё ОК!"); };
        button2.Click += delegate { throw new Exception("Случилос страшное!"); };
    }

    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.Run(new Form1());
    }
}

GC.Collect();

The first thing you have to understand is the difference between programming errors
and exceptions. Programming errors are the misuses of programming abstractions
by programmers. Programming errors are mistakes committed by the programmers
in coding, so that the resulting program code diverges from the what the program
specification allows. Such errors should be corrected before the program is deployed.

Exceptions are unusual events that may occur at runtime even if the program is coded
correctly. Although such an event disrupts the normal execution logic of a program,
they are fully anticipated. That is, exceptions are part of the correct behavior of
a program. The cause of an exception is not an error commit by the programmer. Rather,
it is an unusual runtime event caused by anticipated circumstances.

V> главное!

 e> do_something( find_user_group_name( user_name, user_security_data ) );
 e>

 e> const char * group_name = find_user_group_name( user_name,
 e> user_security_data ); if( group_name )
 e>  do_something( group_name )
 e> else
 e>  ...
 e>

boost::optional<std::string>
find_user_group_name( std::string const& user_name, security_data_t );

V> Паша, ты использовал Янус? А можно поглядеть на отправленные

V> Что-то мне не верится, в то что ты вообще его использовал. Янус как

************** Exception Text **************
System.Data.OleDb.OleDbException: Could not find file 'D:\Users\Pavel\private\internet\janus\janus.mdb'.
at System.Data.OleDb.OleDbConnection.ProcessResults(Int32 hr)
at System.Data.OleDb.OleDbConnection.InitializeProvider()
at System.Data.OleDb.OleDbConnection.Open()
at Rsdn.Janus.DatabaseManager.SetVar(String varName, Object varValue)
at Rsdn.Janus.DBVars.SetVar(String name, Object val)
at Rsdn.Janus.LocalUser.CreateUser(String dbp, String uname, String pwd)
at Rsdn.Janus.OptionsUserForm.SaveUserInfo()
at Rsdn.Janus.OptionsUserForm.btnOk_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
<...>

************** Exception Text **************
System.IO.DirectoryNotFoundException: Could not find a part of the path "C:\Bin\RSDN\Janus\Pavel\config.xml".
at System.IO.__Error.WinIOError(Int32 errorCode, String str)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean useAsync,
String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode)
at Rsdn.Janus.Config.Save()
at Rsdn.Janus.LocalUser.CreateUser(String dbp, String uname, String pwd)
at Rsdn.Janus.OptionsUserForm.SaveUserInfo()
at Rsdn.Janus.OptionsUserForm.btnOk_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
<...>