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

Очень интересно, что все участники дискуссии полностью проигнорировали этот фрагмент отчета. Собственно, ничего удивительного в этом нет, это типичное заблуждение, которое заключается в том, что ПО можно сделать свободным от дефектов и предусматривать какие-то меры восстановления от программных сбоев нет необходимости. И это-то при том, что именно программные ошибки занимают второе место среди причин отказов информационных систем (первое место — cockpit failure), а аппаратные сбои только на третьем.

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

Ссылка по теме: диссертация Joe Armstrong'а на тему "Making reliable distributed systems in the presence of software errors" (http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf)

Fault tolerance actions

• Fault detection The system must detect that a fault (an
incorrect system state) has occurred.
• Damage assessment The parts of the system state affected by
the fault must be detected.
• Fault recovery The system must restore its state to a known safe state.
• Fault repair The system may be modified to prevent recurrence of the
fault. As many software faults are transitory, this is often unnecessary.

Damage assessment

• Analyse system state to judge the extent of corruption caused by a system failure
• Must assess what parts of the state space have been affected by the failure
• Generally based on ‘validity functions’ which can be applied to the state
elements to assess if their value is within an allowed range

Fault recovery

• Forward recovery
• Apply repairs to a corrupted system state
• Backward recovery
• Restore the system state to a known safe state
• Forward recovery is usually application specific — domain knowledge is
required to compute possible state corrections
• Backward error recovery is simpler. Details of a safe state are maintained
and this replaces the corrupted system

Recovery blocks

• Force a different algorithm to be used for each version so they reduce the
probability of common errors
• However, the design of the acceptance test is difficult as it must be
independent of the computation used
• There are problems with this approach for realtime systems because of
the sequential operation of the redundant versions

Fault minimisation

• Current methods of software engineering now allow for the production of
fault-free software.
• Fault-free software means software which conforms to its specification.
It does NOT mean software which will always perform correctly as there
may be specification errors.
• The cost of producing fault free software is very high. It is only cost-
effective in exceptional situations. May be cheaper to accept software faults

V> никак не вяжется.

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.

> // 3:
> for each (String name in names) {
>     try {
>         Person p = personFinder.findPersonByName(name);
>         // ...
>         // do something (2 screens of code)
>         // ...
>     } catch (PatientNotFoundException) {
>     }
> }
>

for each (Record r in records) {
     try {
         City city = cityFinder.findCityByName(r.cityName);
         // ...
         // do something
         // ...

         Hospital hospital = city.findHospitalByName(r.hospitalName);
         // ...
         // do something
         // ...

         Person patient = hospital.findPersonByName(r.patientName);
         // ...
         // do something
         // ...
     } catch (Exception) {
     }
}

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 *) {};
}

Ш>Внесу свои пять копеек в вашу с Павлом совместную диссертацию.

int ftpCommandEnhanced
    (
    int ctrlSock,       /* fd of control connection socket */
    char *fmt,          /* format string of command to send */
    int arg1,           /* first of six args to format string */
    int arg2,
    int arg3,
    int arg4,
    int arg5,
    int arg6,
    char *replyString, /* storage for the last line of the server response or NULL */
    int replyStringLength  /* Maximum character length of the replyString */
    )
    {
    char buffer [128];
    int len;

    if (ftplDebug & FTPL_DEBUG_OUTGOING)
        {
        printErr ("---> ");
        printErr (fmt, arg1, arg2, arg3, arg4, arg5, arg6);
        printErr ("\n");
        }

    /* Format Command to send to FTP server */

    /* The next line will generate a warning with gcc 2.96+, this is O.K. */
    sprintf (buffer, fmt, arg1, arg2, arg3, arg4, arg5, arg6);    len = strlen(buffer);

    /* Append CR LF to format copy to force a single write to TCP */

    sprintf(&buffer[len],"%s","\r\n");
    len = strlen(buffer);

class IsFibonacciNumberException : Exception
{
}
class IsNotFibonacciNumberException : Exception
{
}
static void TestNumber(int n)
{
    TestNumberImpl(n, 1, 1);
}
static void TestNumberImpl(int n, int x1, x2)
{
    if (n == x1)
        throw new IsFibonacciNumberException();
    if (n < x1)
        throw new IsNotFibonacciNumberException();
    int x3;
    try
    {
        checked
        {
            x3 = x1 + x2;
        }
    }
    catch
    {
        throw new IsNotFibonacciNumberException();
    }
    TestNumberImpl(n, x2, x3);
}
static void Foo()
{
    try
    {
        TestNumber(141234);
    }
    catch(IsFibonacciNumberException ex)
    {
        Console.WriteLine("IsFibonacciNumberException");
    }
    catch(IsNotFibonacciNumberException ex)
    {
        Console.WriteLine("IsNotFibonacciNumberException");
    }
}

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

> interface PersonFinder {
> /**
> * returns null if person has not been found
> */
> Person findPersonByName(String name);
> }
>

> interface PersonFinder {
> /**
> * throws checked PatientNotFoundException if person has not been
> found,
> * never returns null
> */
> Person findPersonByName(String name) throws PatientNotFoundException;
> }
>

// 1:
for each (String name in names) {
    Person p = personFinder.findPersonByName(name);
    if (p != null) {
        // ...
        // do something (2 screens of code)
        // ...
    }
}

// 3:
for each (String name in names) {
    try {
        Person p = personFinder.findPersonByName(name);
        // ...
        // do something (2 screens of code)
        // ...
    } catch (PatientNotFoundException) {
    }
}

 d> interface PersonFinder {
 d>  /**
 d>   * throws checked PatientNotFoundException if person has not been
 d> found,  * never returns null
 d>   */
 d>  Person findPersonByName(String name) throws PatientNotFoundException;
 d> }
 d>

boost::optional< Person >
findPersonByName( std::string name );

Person?
findPersonByName( string name );

Optional<Person>
findPersonByName( String name );

boost::optional<Person> person;
if ( ... )
  person = ...;
else if ( ... )
  person = ...;
else
  ...

...

// теперь физически нельзя пропустить тот момент, что person может не иметь
// значения в данной точке

if ( person )
  do_something( *person );

...

void f( T1 t1, T2 t2, boost::optional<Person> );

/**
 * This method gets bitrate.
 * This method is part of the SuperPuper System 
 * Copyright (c) SuperPuper, Inc.  2000, 2001, 2002, 2003, 2004, 2005, 2006
 *    All Rights Reserved
 * This method contains unpublished, confidential and proprietary 
 * information of SuperPuper, Inc. No disclosure or use of 
 * any portion of the contents of these materials may be made without the 
 * express written consent of SuperPuper, Inc.
 * 
 * Author: Vasia Pupkin
 * Description: 
 */
public void getBitrate();

catch(Exception exc) {}

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

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

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> главное!

> ПК>boost::optional< Person >
> ПК>findPersonByName( std::string name );
> ПК>

> ПК>Person?
> ПК>findPersonByName( string name );
> ПК>

> ПК>если нет, тем хуже для Java ):

> ПК>Optional<Person>
> ПК>findPersonByName( String name );
> ПК>

void f( const Person& );
. . .
f( findPersonByName( name ) );

Мы впервые стали применять паттерн нулевого объекта (NullObject), когда Рич Гарзанити обнаружил, что код системы часто проверяет, существует ли объект, прежде чем послать ему сообщение (здесь: "сообщение" — метафора вызова метода в ООП). Мы запрашивали у объекта его метод person, а затем сравнивали результат с null. Если объект присутствовал, мы запрашивали у него метод rate. Это делалось в нескольких местах, и повторение кода в них стало нас раздражать.
Поэтому мы создали объект отсутсвующего лица, который сообщал, что у него нулевой (не null!! — Прим. моё) rate (мы называем наши null-объекты существующими объектами). Вскоре у отсутствующего лица было уже много методов. Сейчас у нас уже больше 80 классов нулевых объектов.
Чаще всего нулевые объекты мы применяем при выводе информации. Например, когда выводится информация о лице, то у соответствующего объекта может отсутствовать любой из примерно 20 атрибутов. Если бы они могли принимать значение null, вывод информации о лице стал бы очень сложным. Вместо этого мы подключаем различные нулевые объекты, которые умеют отображать себя правильным образом. В результате мы избавились от большого объёма процедурного кода.
<...дальше идёт рассказ о применении NullObject's для тестовых транзакций в БД и коллекции бухгалтерских данных...>
<...>
Интересная особенность применения нулевых объектов состоит в том, что почти никогда не возникают аварийные ситуации. Поскольку нулевой объект отвечает на те же сообщения, что и реальный объект, система в целом ведёт себя обычным образом. Из-за этого иногда трудно локализовать проблему, потому что всё работает нормально.
<...>
Помните, нулевые объекты постоянны — в них никогда ничего не меняется. Соответственно, мы реализуем их по паттерну "Одиночка" (Singleton pattern). Например, при каждом запросе отсутствующего лица вы будете получать один и тот же экземпляр этого NullObject-класса.

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:
}

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

V> Отмазка не удачная. Надо было Янус хотя бы попробвать.

 D>>  boolean isPersonExist(String name);
 D>>

К> "коробит".

bool doesPersonExist( String name );

if ( doesPersonExist( "Tom" ) )
  ...

if ( person_exists( "Tom" ) )
  ...

void func1() throw(my_exception) {
    throw my_exception();
}
void func2() throw() {
    func1();
}

void func1() throws MyException {
    throw new MyException();
}
void func2() {
    func1();
}

void func1() throws MyException {
    throw new MyException();
}
void func2() {
    try {
        func1();
    }
    catch(MyException exc) {
        // . . .
    }
}

void func1() throws MyException {
    throw new MyException();
}
void func2() throws MyException {
    func1();
}

 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 );

Failure

Asserts and "by contract" specifications catch programmer errors not run-time
errors! They catch invalid or unknown state problems caused by programming errors.
Do not attempt to recover from assert failures. You are "out of known space."

Don't use asserts for runtime problems such as:
"can't find file"
invalid web site page arg
input arg "rate" too fast

In these cases, you should throw InvalidArgumentException or whatever. The system can
continue to operate in this case.

Asserts/conditions can be taken out after development, but you need input checks always.

What does it mean when contract fails?
If preconditions met, supplier guarantees postconditions.
Failure of precondition implies problem with client.
If postcondition fails, it's a bug in supplier.

D>interface PersonFinder {
D>    /**
D>     * throws checked PatientNotFoundException if person has not been found,
D>     * never returns null
D>     */
D>    Person findPersonByName(String name) throws PatientNotFoundException;
D>}
D>

findPersonByName: aString
findPersonByName: aString ifAbsent: [ ... чегой-то делаем... ]

void f();

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

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