Здравствуйте, Сергей Губанов, Вы писали:
СГ>то это и делать.
Сергей, ваши представления о программировании все еще катастрофически далеки от реальности.
Вы, судя по вашему ответу, считаете, что
а) программа должна трактовать все случаи как равновероятные
б) вся информация для принятия решения доступна ровно там, где выполняется действие.
И то и другое — заблуждения.
Начнем с последнего. Как правило, с неожиданной ситуацией сталкивается код самого нижнего уровня. Что значит "неожиданная ситуация"? Это выражение означает "невозможно выполнить запрошенное действие". Например, мы пытаемся записать килобайт данных в TCP сокет. Упс! Сокет закрылся — например, оборвали кабель, или другая сторона явно разорвала соединение. Внешнему коду, который позвал метод send, вообще ничего не известно про состояние сети. И не может быть известно в силу инкапсуляции — он пишет в какой-то поток, не более того. Это может быть файл, сокет, или блоб-поле в базе данных.
Даже если клиент умен, и предварительно спросил у сокета, можно ли посылать, вовсе не факт, что проблема не возникнет в процессе работы метода:

if(s.IsConnected)
{
  s.Send(myData); /// ошибка где-то в середине передачи
}

Что делать? Ага, проверим код результата:

if(s.IsConnected)
{
  switch(s.Send(myData))
    {
      case SOCKET_DISCONNECTED: ...
        case BUFFER_OVERFLOW: ...
        case ...: ...
        else: // уфф, пронесло, все в порядке.
    }
}

Все здорово до тех пор, пока у нас действительно достаточно информации. Но ведь этот клиентский код, в свою очередь, может быть всего лишь низкоуровневой оберткой над отправкой данных. Что ему делать? По ТЗ надо отсылать письмо. Прекрасно. У нас код нижнего уровня должен знать адрес администратора и уметь отправлять почту.
Чудно. Если же мы оставляем эту работу более высокоуровневому коду, то ему надо откуда-то узнать, что именно случилось. Или же все кончается методом

bool SaveChangesToDbAndSendNotifications()

В случае возврата false надо отправить письмо — и пусть админ гадает, что же там упало. То ли с базой связаться не удалось, то ли нотификации не уехали.
Вообще, вас уже отправили читать Страуструпа — не упрямьтесь, поверьте — он про все это лучше меня написал. И уже давно.

Второй момент — вы предлагаете трактовать все, оговоренное в ТЗ как штатную ситуацию. Оставим пока за бортом вопрос полноты ТЗ. Решим пока, что все неописанные случаи могут приводить к undefined behavior (вообще в наши дни софт с UB — это моветон, если что).

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

if(метеорит_упал)
{
  выполняем_запасные_действия();
}
else
{
  идем_по_основной_ветке();
}

Во-первых, такой код тяжело читать. Он намекает на 50% вероятность попадания метеорита; он содержит ветку основной логики как редкий частный случай и затрудняет понимание собственно решаемой задачи.
Кроме того, зачастую реакция на очень большое количество разнообразных ситуаций более-менее одна. К примеру, асп.нет банально перезапускает повисшее приложение, не вдаваясь в детали — метеорит там, деление на ноль, бесконечный цикл или моль дырку проела. В коде, который действует по методу блондинки, надо предусмотреть реакцию как на отсутствие динозавра, так и на его присутствие.

Во-вторых, это банально влияет на производительность. Если у нас есть частая ветка, то она должна исполняться максимально быстро. Особенно это характерно для исключений — если произошел какой-то сбой, не так уж важно быстро его обработать. Тут бы не совсем не упасть — и то хорошо. Вот, к примеру, процессоры так и делают — предсказывают ветвления и стараются ускорить выполнение частой ветки, в ущерб выполнению редкой, которое приводит к дорогостоящему сбросу конвеера. Но у процессора близорукость сильная, его предсказалка в пределах махоньких циклов хорошо работает. А для более крупных блоков он не поможет.
Код, работающий пессимистично, должен, к примеру, перед снятием денег со счета проверить, а хватит ли их там. Ну и пойти либо снимать деньги, либо писать пользователю отмазку. А поскольку стоимость проверки количества денег примерно такая же, что и стоимость съема денег, мы получаем просад производительности минимум в два раза только за счет пессимизма. (На самом деле все еще намного хуже из-за блокировок и прочих эффектов второго порядка). А вот оптимистичный код пытается выполнить все, как будто все хорошо. И только если вдруг оказалось, что что-то не вышло, выполняется дорогой код раскрутки стека, отката транзакции и т.п.

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

// Бросает исключение OopsItsTailsAgainException в 50% случаев
void ThrowCoinAndCheckHeads() 

enum CoinSides { Heads, Tails};
...

CoinSides ThrowCoin()
{
  try
    {
       ThrowCOinAndCheckHeads();
         return CoinSides.Heads;
    catch(OopsItsTailsAgainException)
    {
        return CoinSides.Tails;
    }
}

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

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

http://www.rsdn.ru/Forum/Message.aspx?mid=1496415&only=1

Автор: Nickolay Ch
Дата: 19.11.05

NC>А вот очень бы хотелось услышать, что вы предлагаете на замену эксепшенов, только мб в новой теме. Они много чем не нравятся, но пока не видно лучших механизмов обработки ошибок.

Я делю ошибки на две категории:
1) ошибки в данных (программа на вход получила неправильные данные);
2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).

Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.
Ошибки категории (2) фатальные, тут программу надо завершать — в программе ошибка, т.е. программа не правильная. Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.

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

psg>А собственно, чем вам не нравятся exceptions?...

Видимо они отсутствуют в Обероне.

Здравствуйте, Сергей Губанов, Вы писали:

IT>>Сейчас чего-нибудь изобразим.

СГ>Написали Вы много,

А ты думал ты в сказку попал. Хватит в солдатиков в песочнице играться, welcome to the real world.

СГ>но принципиальной разницы с предыдущим примером нет.

А вот это мы сейчас и узнаем

Непонятно почему ты пропустил целый лэйер, но да бог с ним. Даже и с ним твой код рабочим назвать нельзя. Точнее он будет работать, но только в чистом, глубоком вакууме, т.к. увлёкшись бесконечными if'ами и &'ми ты совсем забыл сделать Rollback транзакции в случае ошибки. Ошибки двух методов StealSomeXXX ты тоже почему-то решил не обрабатывать. Отговорки типа ну я мол только идею продемонстрировал не принимаются. Впрочем, как раз её ты и "продемонстрировал" — сам понатыкал сосен и сам же в них запутался.

А теперь давай перепишем твой код на C# так чтобы он по идее был рабочим и можно было хоть что-то хоть как-то сравнивать. На строчки скупиться не будем (я же в своём примере не экономил). Я буду писать в своём стиле, но придерживаясь твоей идее. Любые замечания по существу принимаются.

Итак, первый слой — UI. Мой код из предыдущего примера.

void WithdrawalAndGetBalance()
{
    try
    {
        decimal newBalance = AccountManager.WithdrawalAndGetBalance("12345", 100m);
        Console.WriteLine("New balance is: {0}", bewBalance);
    }
    catch (Exception ex)
    {
        Console.WriteLine("Oops: " + ex.Message);
    }
}

Твой вариант (по твоей идее).

void WithdrawalAndGetBalance()
{
  decimal newBalance;
  Errors  err = null;

  if (AccountManager.WithdrawalAndGetBalance("12345", 100m, out newBalance, ref list))
    Console.WriteLine("New balance is: {0}", bewBalance);
  else
  {
    if (err != null)
      Console.WriteLine("Oops: " + err.Message);
    else
      Console.WriteLine("Just oops :xz:");
  }
}

Счёт:
lines: 7:12
if/else/&: 0:4

AccountManager. Мой пример.

public static decimal WithdrawalAndGetBalance(string accountNumber, decimal amount)
{
  Validate(accountNumber);
  Validate(amount);

  return new AccountService().WithdrawalAndGetBalance(accountNumber, amount);
}

Твой вариант.

public static bool WithdrawalAndGetBalance(string accountNumber, decimal amount, out decimal newBalance, ref Errors err)
{
  return Validate(accountNumber, ref err) &&
         Validate(amount, ref err) &&
         new AccountService().WithdrawalAndGetBalance(accountNumber, amount, out newBalance, ref err);
}

Здесь я для наглядности перенёс вызовы на разные строчки, иначе текст не помещался на экран. В общем, далее слишком длинные строки я буду переносить.

lines: 4:3
if/else/&: 0:3
params: 2:4 (output: 0:2)

Но это всё цветочки. Вот они ягодки.

AccountService. Мой пример.

public decimal WithdrawalAndGetBalance(string accountNumber, decimal amount)
{
  Validate(accountNumber);
  Validate(amount);

  using (AccountDataAccessor dataAccessor = new AccountDataAccessor())
  {
    dataAccessor.BeginTransaction();

    decimal balance = dataAccessor.GetBalance(accountNumber);

    if (balance < amount)
      throw new BalanceException("You are freaking bankrupt!");

    balance -= amount;

    dataAccessor.SetNewBalance(accountNumber, balance);

    if (balance > 1000000m)
      dataAccessor.StealSomeForMe(accountNumber, 1.15m);

    balance -= 1.15m;

    if (balance > 10000000m)
      dataAccessor.StealSomeForHomelessPeople(accountNumber, 0.15m);

    balance -= 0.15m;

    dataAccessor.ChargeForService(accountNumber, 10m);
 
    balance -= 10m;

    dataAccessor.CommitTransaction();
 
    return balance;
  }
}

Твой вариант.

delegate bool Do();

public bool WithdrawalAndGetBalance(string accountNumber, decimal amount, out decimal newBalance, ref Errors err)
{
  newBalance = 0m;

  if (Validate(accountNumber, err) && Validate(amount, ref err))
  {
    AccountDataAccessor dataAccessor = new AccountDataAccessor();

    if (dataAccessor.Open(ref err))
    {
      if (dataAccessor.BeginTransaction(ref err))
      {
        if (new Do(delegate()
        {
          if (dataAccessor.GetBalance(accountNumber, out newBalance, ref err))
          {
            if (newBalance < amount)
            {
              err := Errors.NewList(Errors.NewError("You are freaking bankrupt!"), err); // Вот такое вот "кидание исключения"
              return false;
            }
            else
            {
              newBalance -= amount;

              if (dataAccessor.SetNewBalance(accountNumber, newBalance, ref err))
              {
                if (balance > 1000000m)
                {
                  if (dataAccessor.StealSomeForMe(accountNumber, 1.15m, ref err) == false)
                    return false;

                  balance -= 1.15m;
                }

                if (balance > 10000000m)
                {
                  if (dataAccessor.StealSomeForHomelessPeople(accountNumber, 0.15m, ref err) == false)
                    return false

                  balance -= 0.15m;
                  }

                if (dataAccessor.ChargeForService(accountNumber, 10m, ref err))
                  {
                    balance -= 10m;
                    return true;
                }
              }
            }
          }
          }())
        {
          if (dataAccessor.CommitTransaction(ref err))
          {
            dataAccessor.Close();
            return true;
          }
          else
          {
            dataAccessor.Close();
            return false;
          }
        }

        dataAccessor.RollbaсkTransaction();
      }

      dataAccessor.Close();
    }

    return false;
  }
}

lines: 35:71
if/else/&: 3:16 (9 уровней вложенности)
params: 2:4 (output: 0:2)

Нормально, да? Мало того что я на него потратил примерно на порядок больше времени, так ещё после того как я его закончил мне захотелось плакать

Итого имеем. Увеличение количество строк кода в два раза. Усложнение логики за счёт ветвления кода в 5 раз. В принципе, это и есть реальные, даже несколько заниженные цифры. Код начинает ветвиться и разрастаться с ужасающей быстротой, так же быстро теряется наглядность и появляются повторяющиеся фрагменты типа dataAccessor.Close() в примере. Уж извини, старался держаться в рамках твоей идеи. Для того, чтобы это хоть как-то контролировать в реальной жизни (а не в песочнице), некоторые проверки начинают пропускаться или просто забываться делаться с соответствующими последствиями. При внесении изменений в такой, уже казалось бы отлаженный код, внести новый баг — это обычное дело. Чтобы этого избежать, нужно тщательнейшим образом разобраться в этом бреде и делать всё максимально аккуратно, а это время, много времени.

Код с исключениями, как нетрудно заметить, имеет линейную структуру, прост и нагляден. Сделать ошибку в нём трудно, вносить изменения просто.

Некоторые, особенно одарённые товарищи, додумываются вообще до просто таки гениальной идеи. Если мы уже всё равно передаём структуру err, то почему бы в неё не затолкать какой-нибудь код, который можно было бы проверить на клиенте и сделать что-нибудь этакое. Т.е. коды результата уже начинают использоваться не только по своему прямому назначению, но и для других, внебрачных целей. Понять потом логику таких программ можно только "поднявшись" до уровня таких гениев.

Но это ещё не всё.

AccountDataAccessor. Мой код.

public decimal GetBalance(string accountNumber)
{
  return (decimal)ExecuteScalarSp("GetBalance", accountNumber);
}
  
public void SetNewBalance(string accountNumber, decimal amount)
{
  ExecuteNonQuerySp("SetBalance", accountNumber, amount);
}
  
public void StealSomeForMe(string accountNumber, decimal amount)
{
  ExecuteNonQuerySp("StealSomeForMe", accountNumber, amount);
}
  
public void StealSomeForHomelessPeople(string accountNumber, decimal amount)
{
  ExecuteNonQuerySp("StealSomeForHomelessPeople", accountNumber, amount);
}

public void ChargeForService(string accountNumber, decimal amount)
{
  ExecuteNonQuerySp("ChargeForService", accountNumber, amount);
}

Твой вариант.

public bool GetBalance(string accountNumber, out newBalance, ref Errors err)
{
  // oops!!! А ExecuteScalarSp параметра Errors не поддерживает.
  // Ну дятлы её какие-то писали, не додумались до такой классной идее.
  //
  ///////////return (decimal)ExecuteScalarSp("GetBalance", accountNumber);
}

// остальные упсы поскипаны.

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

Да, кстати, использование ref и out параметров считается признаком плохого дизайна. FxCop на это заявляет "Consider a design that does not require that 'parameter_name' be an out parameter".

Сергей,

> http://www.rsdn.ru/Forum/Message.aspx?mid=1496415&only=1

Автор: Nickolay Ch
Дата: 19.11.05

>
> NC>А вот очень бы хотелось услышать, что вы предлагаете на замену эксепшенов, только мб в новой теме. Они много чем не нравятся, но пока не видно лучших механизмов обработки ошибок.
>
> Я делю ошибки на две категории:
> 1) ошибки в данных (программа на вход получила неправильные данные);
> 2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).
>
> Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.

Как именно? Затруднения возникают с тем, что ошибка диагностируется на нижнем уровне, а обрабатываться обычно должна на верхнем. В случае использования, скажем, кодов возврата вводится зависимость от нижних уровней во все промежуточные.

> Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли?

Исключения в первую очередь предназначены именно для (1).

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

S>Ну-ка, приведите мне пример кода, на любом языке, который выполняет следующие действия:
S>1. Снимает заданное количество рублей со счета А
S>2. Кладет это количество рублей на счет Б.
S>3. Записывает данные о транзакции в файл
S>4. Если что-то не удалось сделать, отправляет письмо на определенный адрес, с указанием подробностей ошибки.

S>Пожалуйста, воздержитесь от использования исключений. А мы посмотрим.

Во-первых, и в главных, не "Ну-ка"-йте тут. Что ещё за моду взяли.
Во-вторых, Вы забыли определить какими примитивами разрешено пользоваться.
А то ведь, можно и так:

PROCEDURE Move (VAR src, dst, sum: REAL): BOOLEAN;
BEGIN
  IF src >= sum THEN
    src := src - sum;
    dst := dst + sum;
...

Здравствуйте, Сергей Губанов, Вы писали:

IT>>Может посчитать количество строчек.
СГ>Фигнёй страдаете, однако .

Сергей, и это говорите Вы?

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

IT>...переписать вот такой код без returns?

public class ResultException<T> : ApplicationException
{
    public T Result;

    public ResultException(T result)
    {
        Result = result;
    }
}

public class UndefinedResultException : ApplicationException 
{
}

private static MemberMapper GetNullableMemberMapper(MapMemberInfo mi)
{
    try
    {
        Type type = mi.MemberAccessor.Type;
        
        if (type.IsGenericType == false || mi.MapValues != null)
            throw new ResultException<MemberMapper>(null);
        
        Type underlyingType = Nullable.GetUnderlyingType(type);
        
        if (underlyingType == null)
            throw new ResultException<MemberMapper>(null);
        
        if (underlyingType.IsEnum)
        {
            underlyingType = Enum.GetUnderlyingType(underlyingType);
        
            if (underlyingType == typeof(SByte))    throw new ResultException<MemberMapper>(new NullableSByteMapper. Enum());
            if (underlyingType == typeof(Int16))    throw new ResultException<MemberMapper>(new NullableInt16Mapper. Enum());
            if (underlyingType == typeof(Int32))    throw new ResultException<MemberMapper>(new NullableInt32Mapper. Enum());
            if (underlyingType == typeof(Int64))    throw new ResultException<MemberMapper>(new NullableInt64Mapper. Enum());
            if (underlyingType == typeof(Byte))     throw new ResultException<MemberMapper>(new NullableByteMapper.  Enum());
            if (underlyingType == typeof(UInt16))   throw new ResultException<MemberMapper>(new NullableUInt16Mapper.Enum());
            if (underlyingType == typeof(UInt32))   throw new ResultException<MemberMapper>(new NullableUInt32Mapper.Enum());
            if (underlyingType == typeof(UInt64))   throw new ResultException<MemberMapper>(new NullableUInt64Mapper.Enum());
        }
        else
        {
            if (underlyingType == typeof(SByte))    throw new ResultException<MemberMapper>(new NullableSByteMapper());
            if (underlyingType == typeof(Int16))    throw new ResultException<MemberMapper>(new NullableInt16Mapper());
            if (underlyingType == typeof(Int32))    throw new ResultException<MemberMapper>(new NullableInt32Mapper());
            if (underlyingType == typeof(Int64))    throw new ResultException<MemberMapper>(new NullableInt64Mapper());
            if (underlyingType == typeof(Byte))     throw new ResultException<MemberMapper>(new NullableByteMapper());
            if (underlyingType == typeof(UInt16))   throw new ResultException<MemberMapper>(new NullableUInt16Mapper());
            if (underlyingType == typeof(UInt32))   throw new ResultException<MemberMapper>(new NullableUInt32Mapper());
            if (underlyingType == typeof(UInt64))   throw new ResultException<MemberMapper>(new NullableUInt64Mapper());
            if (underlyingType == typeof(Char))     throw new ResultException<MemberMapper>(new NullableCharMapper());
            if (underlyingType == typeof(Single))   throw new ResultException<MemberMapper>(new NullableSingleMapper());
            if (underlyingType == typeof(Boolean))  throw new ResultException<MemberMapper>(new NullableBooleanMapper());
            if (underlyingType == typeof(Double))   throw new ResultException<MemberMapper>(new NullableDoubleMapper());
            if (underlyingType == typeof(DateTime)) throw new ResultException<MemberMapper>(new NullableDateTimeMapper());
            if (underlyingType == typeof(Decimal))  throw new ResultException<MemberMapper>(new NullableDecimalMapper());
            if (underlyingType == typeof(Guid))     throw new ResultException<MemberMapper>(new NullableGuidMapper());
        }
    
        throw new ResultException<MemberMapper>(null);
    }
    catch (ResultException<MemberMapper> re)
    {    
        return re.Result;
    }
    throw new UndefinedResultException();
}

Здравствуйте, Сергей Губанов, Вы писали:

Гениально! Эдак вы скоро и до exception-ов додумаетесь, колллега!
Как только осознаете, наконец, что служебный код как правило не знает, является ли неудача его выполнения критическим багом или нет для данного случая.

Здравствуйте, Сергей Губанов, Вы писали:
СГ>Программа, я так понимаю, работает в банке со счета которого деньги снимаются.
Прекрасно. Великолепный пример. Что мы из него видим?
1. Все функции обязаны возвращать булевый признак успешности выполнения.
2. Все функции обязаны передавать информацию о причине неудачи.
3. Если нам надо что-то большее, чем текст, в качестве информации о причине неудачи, то мы встряли. Потому что сигнатуры всех функций, имевших несчастье попасть в стек вызовов между тем местом, где мы обрабатываем ситуацию, и тем местом, где она произошла, должны быть модифицированы для передачи этой информации. Что-то более-менее общее мы использовать не сможем.
Более того, у нас нет никакого способа комбинировать обработку, и с ростом количества потенциальных неудач у нас нарастает объем кода, посвященного обработке. Если бы мы обрабатывали исключения, то все было бы сделано одной строчкой.

Вот в приведенном примере — что делать, если журнал не смог записать успешную запись в файл? О да, в данном случае он отправит письмо "внутри". Потому, что он инкапсулирует как запись протокола, так и сообщения об ошибках. А если бы мы разделили эту функциональность (что, в общем-то, более правильно, т.к. она ортогональная), то в коде пришлось бы отдельно проверять, удалось ли в провести запись в файл.

Здравствуйте, Сергей Губанов, Вы писали:

M>>Но главное — да приведите же наконец хоть одну причину, по которой от исключений нужно отказаться.

СГ>Признаюсь, едва ли мне по силам найти хоть одну причину убедившую бы Вас. Впрочем, и Вам тоже едва ли по силам найти серьёзную причину по которой исключения должны быть встроены в язык, а не в библиотеку.

Исключения, встроенные в библиотеку (по крайней мере, основывающиеся на раскрутке стэка) — это очень, очень плохо. Посмотрите на OS Symbian и ее C++ API — там как раз исключения поддерживаются на уровне библиотеки (API), а не на уровне языка. Во что это выливается на практике? В кромешный ад — не забыть запихнуть объект в CleanupStack, чтобы по возникновении исключения он был корректно уничтожен, не забыть положить туда же объект, созданный на стэке, причем cleanup операцией для него будет являться не деструктор, а некий виртуальный метод Close, что автоматически означает необходимость вызова этой же Close при нормальном завершении времени жизни объекта (вручную! ). Это также означает необходимость two phase construction — сначала для объекта вызывается его конструктор (который ничего практически не делает!) и только затем (после заталкивания его в CleanupStack) — функция ConstructL, которая и выполняет фактические конструирующие действия, небезопасные с точки зрения исключений. Тем самым очень сложно становится полагаться на RAII.

Но самое интересное во всем этом — это то, что ничего больше и нельзя было сделать на уровне библиотеки. Да, это криво, но это — максимум, что можно выжать из библиотечного кода, не трогая компилятор. Т.к. только компилятор владеет списком автоматических объектов. Отсюда вывод — исключения, реализованные на уровне библиотеки, на порядок увеличивают объем работы программиста, не привнося вместе с тем никаких преимуществ.

Вот такой вот практический опыт работы с исключениями, реализованными на уровне библиотеки.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.

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

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

E>>>А вообще, кроме классика Н.Вирта, есть еще и классик Б.Страуструп. В его книге "Язык программирования С++. 3-е издание" есть целая глава #14, которая посвящена обработке исключений. Тебе бы не мешало прочитать из нее хотя бы 14.1 (Обработка ошибок [except.error]) и 14.1.1 (Альтернативный взгляд на исключения [except.views]). Там очень сжато и точно описываются разные стратегии диагностики ошибок и роль в этом деле исключений.
E>>>Note. Названия разделов я привел из англиского варианта книги, т.к. русский вариант у меня на работе.
iZEN>>Ещё есть один классик т.н. "контрактоного программирования" (кстати, последователь Н.Вирта, сейчас работает в ETH) — Бертран Мейер, автор языка Eiffel.
iZEN>>Стоит почитать и его.
E>Стоит, безусловно. А что именно? Если можно URL, т.к. у нас достать печатное издание крайне проблематично.
"Объектно-ориентированное конструирование программных систем", Бертран Мейер, изд. Русская редакция, 2005, 1232 стр., ISBN: 5-7502-0255-0

Несколько определений и правил из главы "Когда контракт нарушается: обработка исключений".

Определения

• Успех, Отказ. Вызов программы успешен, если он завершается в состоянии, удовлетворяющем контракту. Вызов считается отказом, если он не успешен.
  
• Исключение — событие периода выполнения, которое может стать причиной отказа.
  
• Отказы и исключения. Отказ программы — причина появления исключения в вызывающей программе.
  
• Случаи отказа. Вызов программы приводит к отказу, если и только если встретилось исключение, и программа не смогла с ним справиться.

Далее приводятся примеры. Как не следует обрабатывать исключения в языках Си (сигналы в UNIX) и Ада — рассмотрены тривиальные ошибки программиста.
<...>

Принципы дисциплинированной обработки исключений

• Повторение (Retrying) — попытка изменить условия, приведшие к исключению, и выполнить программу повторно, начиная всё сначала.
  
• Отказ (Failure) — известный также как Организованная Паника (organized panic): чистка стэка и других ресурсов, завершение вызова и отчёт об отказе перед вызывающей программой.

Ключевые концепции

• Обработка исключений — это механизм, позволяющий справится с неожиданными условиями, возникшими в период выполнения.
  
• Отказ — это невозможность во время выполнения программы выполнить свой контракт.
  
• Программа получает исключение в результате: отказа вызванной ею программы, нарушения утверждений (например, assert. — Прим. моё), сигналов аппаратуры или операционной системы об аномалиях, возникших в ходе их работы.
  
• Программная система может включать также исключения, спроектированные разработчиком.
  
• Программа имеет два способа справиться с исключениями — Повторение вычислений (Retry) и Организованная Паника. При Повторении тело программы выполняется заново. Организованная Паника означает готказ и формирование исключения у вызывающей программы.
  
• Формальная роль обработчика исключений, не заканчивающегося retry, состоит в восстановлении инварианта, но не в обеспечении контракта программы. Последнее всегда является делом тела программы. <...> Формальная роль ветви, заканчивающейся retry, состоит в восстановлении инварианта и предусловия так, чтобы тело программы могло попытаться в новой попытке выполнить контракт.
  
• Базисный механизм обработки исключений, включаемый в язык, должен оставаться простым, если только поощрять прямую цель обработки исключений — Повторение или Организованную Панику. Для приложений, нуждающихся в более тонком контроле над исключениями, введён класс EXCEPTIONS, позволяющий добраться до свойств каждого вида исключений и провести их обработку. Этот класс позволяет создавать и обрабатывать исключения разработчика (в языке Eiffel. — Прим. моё).

E>Я упомянул разделы 14.1 и 14.1.1 книги Страуструпа потому, что там описываются следующие стратегии поведения в случае возникновения ошибок:
E>

E>
• аварийное завершение программы;
  E>
• возврат значения, определяющего наличие ошибки;
  E>
• возврат корректного значения, но оставление программы в некорректном состоянии;
  E>
• вызов специально предоставленных функций для реакции на ошибки
  E>

E>и приводится сравнение этих вариантов с вариантом использования исключений.

E>Ну и еще одно соображение. Исключения, в отличии от того же контрактного программирования, стали широко призанным и адаптированным механизмом. C++, Java, C#, Python, Ruby, Ada, Smalltalk -- везде есть исключения. Конечно, это не панацея от всех болезней, и применять их нужно осторожно. Тем не менее, вряд ли идея исключений получила бы такое широкое распространение, если бы она не была настолько удачной.
Как видите, Бертран Мейер имеет ясное представление об исключениях, и эта тема — одна из важнейших в контрактном проектировании/программировании. Он ни в коей мере не отрицает возможность и нужность исключений, наоборот — чётко формализует и внедряет в процесс проектирования ПО в виде неотъемлемой части.
Поэтому исключения нужно применять не "осторожно", как вы предлагаете, а просто-напросто ГРАМОТНО работать с ними. Это целая "субархитектура" (по аналогии с суб-культурой) в основании любой программной системы, и игнорировать её нельзя.

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

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

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

psg>>>А собственно, чем вам не нравятся exceptions?...

IT>>Видимо они отсутствуют в Обероне.

psg>Это не повод, в обероне много что отсутствует

А кто сказал, что не нравятся только exceptions?...

Здравствуйте, Сергей Губанов, Вы писали:

E>>А что программе-то делать в этих условиях?

СГ>Странный вопрос. Что в техническом задании на программу для этого случая написано, то и делать.

Знаешь, Сергей, этот ответ напоминает замечательное требование, которое выдвигают заказчики: "Программа должна делать то, что нужно. И должа делать это так, как нужно". Не умея при это объяснить что такое "что нужно" и что такое "как нужно".

Вернемся к выходу из строя модуля памяти. Есть OS (например, HP NonStop Kernel) которые прекрасно справляются с выходом из строя практически всех модулей памяти (за исколючением хотя бы одного). Но что это означает для программы? А означает это то (утрируя), что следующий код:

My_Object * o = new My_Object();

// Вот в этой точке приведет к обращению по недоступному адресу.
o->set_some_param( 13 );

хотя само выделение памяти произошло успешно. И как в данном случае бороться с ошибками? Неужели нужно писать:

My_Object * o = new My_Object();

// Вот в этой точке приведет к обращению по недоступному адресу.
o->set_some_param( 13 );
if( errno )
    // Ба, да ведь запись у нас не прошла. Что у нас в ТЗ записано?
    do_something_from_tz();
else
    // Работаем дальше...

Во что же тогда программирование превратиться?

СГ>Если, например, в ТЗ написано, что при недостаточном месте на диске надо предложить пользователю:
СГ>а) очистить диск, потом повторить операцию сохранения;
СГ>б) предложить сохранить на floppy/CD-RW/и т.д.
СГ>в) предложить отправить по электронной почте...
СГ>то это и делать.

Вопрос "Что делать?" должен быть понятен еще до написания кода (просто по определению). Меня интересует, как это делать. При наличии исключений я могу просто написать последовательность действий:

try
    {
        db_transaction_t trx( db_stream );
        db_stream << header << description << footer;
        trx.commit();
        
        // При возникновении исключения trx сам откатит транзакцию в своем деструкторе.
    }
catch( const db_exception & x )
    {
        // Обработка различных ситуаций: нет места, защита от записи, нет прав, отмонтированное устройство...
        process_db_exception( x );
    }

А что мне предлагается делать без исключений?

db_trx_id_t trx_id = db_stream.start_trx();
if( !errno )
    {
        db_stream << header;
        if( !errno )
            {
                db_stream << description;
                if( !errno )
                    {
                        db_stream << footer;
                        if( !errno )
                            {
                                db_stream.commit_trx( trx_id );
                                if( !errno )
                                    return 0;
                            }
                    }
            }
        
        int old_errno = errno;
        db_stream.rollback_trx( trx_id );
        errno = old_errno;
    }

process_db_error();

Речь идет об этом?

reductor wrote:

> Если чуть серьезнее, то логика — это штука немного формальная. Желание
> джампнуть куда-нибудь (частным случаем чего кроме GOTO является и
> множественный return), и сделать поведение программы непредсказуемым,
> это не от большого понимания того, что сам делаешь.
> А еще — это не религия и понятие "фанатизм" к ней не применимо. Люди
> или могут обосновать свой вывод и выбор или нет.

Нет, это уже религия. Все нормальные программисты уже давно перестали
флеймить по поводу GOTO и структурного программирования, так как по
нынешним меркам это уже далеко не самый главный вопрос. Все
программисты, которых я знаю, думают примерно так: "GOTO это плохо?" —
"Плохо". "Структурное программирование хорошо?" — "Да". "Единый return,
выход из вложенных циклов по флагам, отсутствие break — оно надо?" — "А
нафига?"

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>PROCEDURE Move (VAR src, dst, sum: REAL): BOOLEAN;
СГ>BEGIN
СГ> IF src >= sum THEN
СГ> src := src — sum;
СГ> dst := dst + sum;
СГ>...
СГ>[/pascal]

Совершенно очевидно, что такой код к использованию не пригоден, правда?
А вообще — слишком много внимания к проблеме, не стоящей выеденного яйца. Комрад не понимает, что такое исключения и пытается бороться с несуществующими проблемами. Пускай борется в одиночку.

Сергей Губанов wrote:

> C>Нет, это как раз его дело. Так как он должен откатить транзакцию и
> передать "выше" сообщение об ошибке.
> Тогда надо использовать другой базис примитивных операций. Ибо в
> выбранном базисе состоящей всего из одной примитивной операции
> "Начислить":
> PROCEDURE (this: СчётВУдалённомБанке) Начислить* (сумма: Деньги;
> откого: ОтКого; VAR err: Errors.List): BOOLEAN, NEW, ABSTRACT;
> после свершившегося начисления, откат назад невозможен.

Это почему же? Вполне возможно, просто вводится понятие "транзакция".

Грубо говоря, в начале выполнения блока операций мы каким-то образом
запоминаем текущее состояние системы. Далее делаем нужные нам операции
(причем операции не обязаны знать о транзакционности). В случае ошибки
одной из операций, мы просто возвращаем состояние системы в сохраненное
в начале транзакции ИЛИ помечаем измененные данные как неправильные и
дальше их не используем.

Дальше вполне логичный шаг — делим код на классы по обеспечиваемой
гарантии безопасности:
1. Небезопасный — в случае ошибок будет работать неправильно.
2. Базовая гарантия — в случае ошибок сработает штатно, но данные
системы останутся в ошибочном состоянии.
3. Сильная гарантия — в случае ошибок система вернется в предсказуемое
состояние, допускающее дальнейшее использование.
4. Гарантия отсутствия ошибок — система не может попасть в ошибочное
состояние.

Особенно хорошо вопрос по безопасности исключений исследован в С++, так
как там последствия неправильной обработки обычно намного более видимы,
чем в C# или подобных язках. Есть очень хорошая книжка — "Exceptional C++".

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

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

R>Я? представляю, а что?
R>А можно ли услышать что такое "реальные объемы"? А то может у меня какие-то они нереальные, мало ли.
R>И почему даже если так, то нужно делать код менее верифицируемым, чем можно?

Кстати, сам я тоже склоняюсь к мысли, что по-возможности надо верифицировать код, а не побочные эффекты его работы. Заявление о том, что "раз программа прошла все тесты, значит она правильная" не вызывает у меня ничего, кроме скепсиса.

Однако, "реальные объемы кода" — это такие объемы в пересчете на одного разработчика, которые приняты сейчас в реальных проектах. Если С++ программист должен выдавать от 200 и до... (иногда 400-600) строк в день, то верификация таких объемов займет в разы больше времени и потребует гораздо более дорогих в почасовом плане ресурсов, чем ресурс автора целевого кода. В общем подход, основанный на полной верификации кода элементарно неприемлим для многих контор.

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

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

Далее, насчет пресловутого if-else. Разумеется, что если некое действие имеет некий эффект, то этот эффект необходимо проверить полностью (не только по if-else, возможны множественные проверки по switch-case), с этим никто не спорит.

Другое дело, что писать else после return не рекомендует даже MSDN, и я тут полностью соглашусь, ибо ответвление в else здесь происходит само "механическим" образом. Зато как бенефиты мы повышаем читабельность (меньше уровней вложенности, скобок {}, begin-end и т.д.), и кое-где говорится о повышении эффективности (слабо верится для современных компиляторов).

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

Таким образом, верификация даже такого кода может быть полной. Другое дело, что мы не сможем верифицировать отдельно взятый участок (вернее можем, поясню далее), т.е. необходимо больше информации, о том, что происходит "неявно" для случая С++. Однако, и здесь нас ожидают бенефиты. Мы можем построить верификацию кода иерархически, т.е. проверифицировать сначала "прочистку", а затем код, использующий ее неявный вызов. Ввиду того, что целевой код неплохо сокращается в случае множественного return (или использования exceptions как продвинутой разновидности), мы можем получить как раз больше возможностей для верификации на "реальных объемах".

-----------
Кстати, ты писал, что ничего не имеешь против exceptions. Тем более странно твое отрицание множественного return. Для меня эти возможности как бы равнозначные, с тем отличием, что exceptions — это автоматизированная разновидность обсуждаемого + возможность синтаксически обощать места кода по обработке ошибки.

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

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

E>Самое время синтаксический оверхед померять

Обязательно померяем И развернём его однострочный код, чтобы строчки посчитать, и количество ветвлений программы учтём. И даже поставим на вид то, что тырить без проверки результата не хорошо. Ну а уж за незакрытую транзакцию будем пинать ногами от всей души

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Я делю ошибки на две категории:

Изначальный посыл неправильный.

исключительная ситуация это есть нечто ожидаемое но исключительное.

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

E>А что программе-то делать в этих условиях?

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

Если, например, в ТЗ написано, что при недостаточном месте на диске надо предложить пользователю:
а) очистить диск, потом повторить операцию сохранения;
б) предложить сохранить на floppy/CD-RW/и т.д.
в) предложить отправить по электронной почте...
то это и делать.

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

СГ>> кандидату: 100% от нормы обычного человека, доктору: 500% — 1000% от нормы обычного человека академику, ну скажем, 20'000% от нормы....

P>Отлично. А сколько программисту от нормы обычного человека? А, кстати, обычному человеку?

Вы такие вопросы сложные задаёте, едва ли моих личных процентов от нормы хватит чтобы сообразить как ответить.
Хотя попробую. Дело в том что есть количественные (приблизительные) соотношения: на каждого 1 доктора приходится по 10 кандидатов, а на 1 академика приходится 10-20 докторов. Поскольку любой кандидат хочет стать доктором, и любой доктор хочет стать академиком, то отсюда заключаем, что докторами становятся люди которые в 10 раз умнее чем усреднённый кандидат; а академиками становятся люди которые в 10-20 раз умнее чем усреднённый доктор. Соотношения сильности умов между кандидатами и программистами на основании только лишь их количественных соотношений получить нельзя так не все программисты всенепременно хотят стать кандидатами.

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

В>Например, в текстовом редакторе вы переводите каретку на строку вверх. Допустим, этим занимается отдельный метод, который возвращает номер новой текущей строки. А строчка вверху короче и поэтому каретка также будет смещена по колонкам. В этом случае метод бросает исключение, в котором содержатся новые координаты каретки.

В>То есть, мы хотели изменить Y-координату каретки, но также изменилась и X-координата — это не ошибка, это исключительная ситуация.

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

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

ГА>>>Избежать-то всегда можно. Вот и избегают некоторые фанатичные последователи этого правила, выходя из цикла 3-го уровня вложенности с помощью булевских флагов или даже бросая исключения .

IT>>Совершенно верно. Это правило было актуально 15 лет назад. Сегодня оно является таким же устаревшим как венгерка и SELECT*.

R>Устарело?
R>Что, разобрались с остановкой тьюринг-полного автомата?

При чем тут?

R>научились писать после этого статические анализаторы, которые находят и предсказывают поведение GOTO и множественного return?

Да, особенно хорошо это работает в том же С++ с инлайн-подстановкой тел ф-ий.

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

При чем тут? Вот стандартный алгоритм линейного поиска с 2-мя return:

      { begin }
          |
          |
      [ i:=0 ]
          |
+-------> |             0
|    < i < len(array) > ----- { return -1; }
|         | 1
|  0      |
+---< array[i]=x?>
          | 
          |
      { return i; }    


for(int i=0; i<arr.size(); i++)
  if(arr[i]==x)
    return i;
return -1;

Очень хорошо всеми понимается

R>Наконец, уже написали компиляторы нормально это разруливающие и процессоры, у которых нет оверхеда от этого?

Компилятор именно в 1 return и разруливает, при чем ему остается гораздо больше свободы для оптимизации, чем при явном указании, как именно на 1 return надо выйти. Как пример — обратное развертывание while и for — циклов.

Поэтому все остальные аргументы — слабоваты, из-за того, что компилятор сам сводит кол-вы выходов из ф-ии к требуемому кол-ву. А аргумент насчет понимания логики программы — субъективный и сильно надуманный. Гораздо большее число программистов совершенно не испытывает затруднений при разработке кода с многими return.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Грамотно расставленные ассерты предусловия, инвариантов и постусловия — это доказательство правильности программы вообще...

Абсурд. ИМХО.

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

B>)

Вывести в чисто поле, поставить лицом к стенке и пустить пулю в лоб

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

E>Во что же тогда программирование превратиться?

А Вы подумайте.

Если верить рекламе языков (Java, C#), то "программирование — это лёгкое и непринуждённое занятие". Обманыевает эта реклама, хотя бы пять процентов головного мозга напрягать всё-равно надо.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Privalov, Вы писали:

СГ>>> кандидату: 100% от нормы обычного человека, доктору: 500% — 1000% от нормы обычного человека академику, ну скажем, 20'000% от нормы....

P>>Отлично. А сколько программисту от нормы обычного человека? А, кстати, обычному человеку?

СГ>Вы такие вопросы сложные задаёте, едва ли моих личных процентов от нормы хватит чтобы сообразить как ответить.
СГ>Хотя попробую. Дело в том что есть количественные (приблизительные) соотношения: на каждого 1 доктора приходится по 10 кандидатов, а на 1 академика приходится 10-20 докторов. Поскольку любой кандидат хочет стать доктором, и любой доктор хочет стать академиком, то отсюда заключаем, что докторами становятся люди которые в 10 раз умнее чем усреднённый кандидат; а академиками становятся люди которые в 10-20 раз умнее чем усреднённый доктор. Соотношения сильности умов между кандидатами и программистами на основании только лишь их количественных соотношений получить нельзя так не все программисты всенепременно хотят стать кандидатами.

Так и не все кандидаты могут стать программистами, ничего личного

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

A>А вот и нет в паскале только 1 оператор в модуле тоже
A>нужно писать BEGIN END
A>ві наверное на VB перепрограммировали.

Ты не прав, паскаль и компонент паскаль — вещи разные, у Вирта целый зоопарк зверушек, каждая с похожей, но чуть другой мордочкой

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

R>Корректная работа кода не означает автоматически, что код выполняет то, что предполагалось. Это так же не означает что код соответствует спецификации и, соответственно, что можно считать его доказаным или хотя бы без багов.

Корректно работающий в соответствии со спецификацией код совсем не обязательно выполняет то, что предполагалось.
Это эмпирический вывод, основывающийся на том, что:
a) спецификации так же содержат ошибки;
b) заказчик может не суметь четко описать свои пожелания и ожидания.
Доказать я его не могу.

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

>> Так может такие проверки должны быть штатными и использоваться не
>> только в режиме отладки?

C>А зачем? assert показывает ошибки программиста, а не пользователя. То
C>есть ни при каком варианте работы событий пользователь не должен его
C>получить, а значит и включать его не надо.

Для библиотечного кода эти проверки должны присутствовать и как правило присутствуют, загляни хотя бы в исходники .NET FW.

C>В рельной жизни assert'ы обычно оставляют в бэта-версиях, и выкидывают в релизах.

В реальной жизни фича отладчика, о которой я говорил выше, позволяет отловить всё тоже самое и без всякого замусоривания кода макросами. В общем, в ASSERT похоже тоже можно относить к устаревшим средствам и правилам типа венгерки, SELECT* и единственного return.

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

PD>Я не собираюсь предлагать что-то вместо эксепшн, но вот идею их я бы расширил. Сейчас — это просто уведомление о чем-то. Я бы добавил в них возможность исправления, если, конечно, возможно.

PD>Происходит исключение. Выбрасывется экземпляр класса исключения. Это экземпляр получает доступ к классу/методу, где произошло исключение, анализирует причину и изменяет состояние класса, после чего, возможно, повторяет операцию, вызвавшую исключение.
PD>Я бы называл это "теневой обработкой исключений"

Это так называемые "продолжаемые исключения". Работает в языках, не разрушающих стек во время поиска обработчика. Например в ST, CLOS.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>В первую очередь Zero-Overhead Exception Handling было реализовано как раз в модульной системе!

Я бы не стал утверждать, что первая реализация zero-overhead EH была реализована в Oberon. Существуют два основных подхода к реализации исключений — "code" and "table" approaches:

В "code" подходе все структуры, связанные с обработкой исключений располагаются в стеке и непосредственно в секции кода процедур. И обработка исключений происходит небесплатно, даже при "безошибочном" выполении программы.

В "table" подходе все структуры, связанные с обработкой исключений, располагаются в специальных таблицах в read-only памяти и задействуются только при выбрасывании исключения. Насколько я понял, это и есть тот самый zero-overhead, описаный в статье. Для C++ это уже не совсем zero-overhead, поскольку этот подход требует дополнительных таблиц, иногда не маленьких. Но в Обероне этот оверхед встроен by design.

Что касается компиляторов, то vc++ использует code approach поверх платформенных исключений x86. А g++, если не ошибаюсь, использует то один, то другой подход в зависимости от целевой платформы.

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

E>Стоит, безусловно. А что именно? Если можно URL, т.к. у нас достать печатное издание крайне проблематично.

Object Oriented Software Construction

Здравствуйте, Сергей Губанов, Вы писали:

S>>Вот в приведенном примере — что делать, если журнал не смог записать успешную запись в файл?

СГ>Что делать кому? Объекту "ЛокальныйСчёт" по этому поводу точно делать ни чего не надо, он свою задачу выполнил на 100%, а уж как там внутри объекта "Журнал" чего-то стряслось — не его дело.
Что делать программе? Нам не удалось записать операцию в журнал. Это может иметь катастрофические последствия для бизнеса — грубо говоря, мы вообще не знаем про эту операцию. Сегодня у нас никакой катастрофы нет, а завтра логика потребует изменения. Что, перепишем всю программу сверху донизу?

СГ>Ничего подобного.
СГ>1) Не все процедуры обязаны возвращать булевый признак успешности. Например, операция рапорта о чём-то произошедшем, ничего не должна возвращать — это никому не интересно кроме неё самой.
Сегодня не интересно. Процедура, вообще говоря, не должна принимать такие решения. Для улучшения повторного использования она должна дать возможность вызывающему коду гибко контролировать весь процесс.
СГ>2) Не все процедуры обязаны возвращать информацию о причине неудачи. Ну не получилось, что-то сделать — иногда интересно узнать почему, а иногда — причина по барабану.
То же самое. Заранее знать, по барабану или нет, нельзя. Это принципиальный момент. Без понимания этого вам не удастся двигаться дальше. Архитектура, которая требует массовых изменений по всему коду для внесения небольших изменений — обречена.
СГ>3) С чего Вы взяли, что информация о неудаче есть обязательно текст? Можно возвращать текст, можно число, можно указатель на абстрактный объект, и т.д.
Я этого ни с чего не взял. В данном примере потребовалось всегда возвращать текст — поскольку реакция на любую проблему должна отправлять текстовое сообщение. Я упомянул о том, что в более сложной ситуации придется придумывать более сложные структуры.
СГ>Вот, пример полиморфной информации об ошибке:
Совершенно верно. Это объектно-ориентированный вариант "кода результата". Поздравляю, вы успешно его изобрели. Он намного лучше, чем HRESULT из COM.
Он позволяет передать практически любую релевантную информацию.

Это почти что механизм исключений. Можно даже написать аналог набора блоков Catch — в обероне же вроде был свитч по фактическому типу, не так ли? Вместо корявого набора if, который вы привели.

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

public Exception ToString(out string result)
{
  int a1;
  Exception r = SomeMethod(out a1);
    if (r != null)
        return r;
    string s1;
    r = SomeOtherMethod(out s);
    if (r != null)
        return r;
    result = a1.ToString()+s;
    return null;
}

То есть каждый-каждый вызов приходится оборудовать проверкой результата и передачей выше по стеку.
Теперь нельзя каскадировать вызовы и писать выражения:

int a = GetX()*GetY(); // ай-яй-яй!

вместо этого мы будем писать так:

int x, y, a;
Exception r;
r = GetX(out x);
if (r != null)
        return r;
r = GetY(out y);
if (r != null)
        return r;
r = Multiply(x, y, out a);
if (r != null)
        return r;

Здорово, правда? Только не надо рассказывать про то, что мы можем себе позволить игнорировать ошибки в GetX, GetY, или что при умножении не может ее возникнуть — еще как может! IntegerOverflow, пожалте-ка. А приведенный фрагмент пишется в библиотечном коде, который не имеет никакого представления о том, как правильно реагировать на проблемы. Ну, может на некоторые конкретные он и знает, как реагировать (тогда вместо сравнения r c null будет какой-то более сложный код), но все остальные (а в общем случае он не знает, какие они будут), обязан отдать вызывающему коду. В данном случае мы имеем десятикратное раздувание кода.

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

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

Здравствуйте, Сергей Губанов, Вы писали:

IT>>А теперь добавь сюда какую-нибудь вменяемую информацию об ошибке, сделай так чтобы TransferMoney возвращала новый баланс счёта и протащи это через 4-5 вызовов.

СГ>Легко. Приведите код с exception, а я его переделаю в код без exception. Да, и еще у меня будет большая просьба: после того как я это сделаю — уже ни когда не предлагать делать это еще раз — сколько можно одно и тоже писать? Смысл-то как это делается и так уже понятен.

Сейчас чего-нибудь изобразим.

Итак, первый слой — UI.

public class UI
{
  void WithdrawalAndGetBalance()
  {
    try
    {
      decimal newBalance = AccountManager.WithdrawalAndGetBalance("12345", 100m);
      Console.WriteLine("New balance is: {0}", bewBalance);
    }
    catch (Exception ex)
    {
      Console.WriteLine("Oops: " + ex.Message);
    }
  }
}

AccountManager — лэйер через который UI общается с сервером. Инкапсулирует методы доступа к серверу.

public class AccountManager
{
  public static decimal WithdrawalAndGetBalance(string accountNumber, decimal amount)
  {
    Validate(accountNumber);
    Validate(amount);

    return new AccountService().WithdrawalAndGetBalance(accountNumber, amount);
  }
}

AccountService — объект на стороне сервера.

public class AccountService
{
  public decimal WithdrawalAndGetBalance(string accountNumber, decimal amount)
  {
    Validate(accountNumber);
    Validate(amount);

    using (AccountDataAccessor dataAccessor = new AccountDataAccessor())
    {
      dataAccessor.BeginTransaction();

      decimal balance = dataAccessor.GetBalance(accountNumber);

      if (balance < amount)
        throw new BalanceException("You are freaking bankrupt!");

      balance -= amount;

      dataAccessor.SetNewBalance(accountNumber, balance);

      if (balance > 1000000m)
        dataAccessor.StealSomeForMe(accountNumber, 1.15m);

      balance -= 1.15m;

      if (balance > 10000000m)
        dataAccessor.StealSomeForHomelessPeople(accountNumber, 0.15m);

      balance -= 0.15m;

      dataAccessor.ChargeForService(accountNumber, 10m);
 
      balance -= 10m;

      dataAccessor.CommitTransaction();
            
      return balance;
    }
  }
}

AccountDataAccessor — тупая доступалка к БД.

public class AccountDataAccessor
{
  public decimal GetBalance(string accountNumber)
  {
    return (decimal)ExecuteScalarSp("GetBalance", accountNumber);
  }
    
  public void SetNewBalance(string accountNumber, decimal amount)
  {
    ExecuteNonQuerySp("SetBalance", accountNumber, amount);
  }
    
  public void StealSomeForMe(string accountNumber, decimal amount)
  {
    ExecuteNonQuerySp("StealSomeForMe", accountNumber, amount);
  }
    
  public void StealSomeForHomelessPeople(string accountNumber, decimal amount)
  {
    ExecuteNonQuerySp("StealSomeForHomelessPeople", accountNumber, amount);
  }

  public void ChargeForService(string accountNumber, decimal amount)
  {
    ExecuteNonQuerySp("ChargeForService", accountNumber, amount);
  }
}

Все алгоритмы и имена методов вымышленные. Совпадения случайны.

ГА>А можно маленький примерчик применения CPS вместо исключений?

Да, конечно.
вот здесь подробное описание того, что в Common Lisp: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html
С очень понятным объяснением, я считаю. И в сравнении с явой и питоном. Умру, но лучше не напишу.


А в Хаскеле — например, самый, наверное, простейший вариант:

module Main where

import IO

main :: IO () -- Это комментарий
main = let processError e = -- Обработчик ошибки I/O. Типизируется как :: IOError -> IO ()
               putStrLn . show e
       in doIO "Who the hell are you? " `catch` processError -- Передача action'a и обработчика конструтору catch
    where
        doIO out = do -- Обернутый I/O action
            putStrLn out >> hFlush stdout
            str <- getLine
            putStrLn ("Nice to meet you, " ++ str)

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

main :: IO ()
main = catch (do putStrLn "Who the hell are you? " >> hFlush stdout
                 getLine >>= putStrLn . (++) "Nice to meet you, ")
             (\e -> putStrLn $ show e)

Функция-конструктор catch оборачивает экшены ввода-вывода в вариантный тип и в зависимости от его значения вызывается соответствущий обработчик.
Это в принципе более всего похоже на обычные иксепшены (за тем исключением, что обернутый action и обработчик могут общаться друг с другом напрямую за спиной catch, т.к сами — обычные функции и стек остается целым) и наверное самый простой способ отделить обработчик от основной логики.
+ несмотря на то, что ничто не мешает создать самому сколь угодно навороченную систему обработки, модуль Control.Exception определяет огромное количество готовых примитивов:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html

Здравствуйте, Сергей Губанов, Вы писали:


СГ>2) Следующий ненадуманный пример.
СГ>Есть виндос-форма, в поля которой пользователь вводит числа.
СГ>Если пользователь ошибся и ввел неправильную строку, то надо ему об этом сообщить.
СГ>Но стандартная функция
СГ>

СГ>int System.Int32.Parse (string str)
СГ>

СГ>имеет ошибку в дизайне — она кидает исключенние, приходится либо писать свой парсер чисел (что влом)
СГ>либо писать так :

Как насчет использования bool System.Int32.TryParse(string s, out int result) в тех случаях, когда исключение не желательно?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Чего-то не понял а Вашей шутки. Конечно, безусловно, однозначно, в любую погоду никакие юнит-тесты в принципе не способны заменить ассерты. Грамотно расставленные ассерты предусловия, инвариантов и постусловия — это доказательство правильности программы вообще, а юнит-тесты — лишь свидетельство, что данные конкретные тесты проходят, но не доказательство правильности программы вообще.

Доказательств правильности программы пока не существует вообще. Асёрты помогают выявить проблему и только. Грамотно расставленные асёрты помогают выявить проблему на ранней стадии. Но они даже не помогают её локализовать. Хотя в принципе, это возможно, но в таком коде за асёртами самой логики не будет видно

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

Лучший способ борьбы с инвариантами — это не асёрты, а изничтожение самих инвариантов, чем их меньше, тем меньше проблем. Но это мы сейчас опять скатимся во флейм stateless vs stateful.

Юнит тесты vs asserts обладают одним существеным преимуществом. Они доказывают, что сделанные изменения не нарушили работоспособность системы. В случае с асёртами мне никто не запрещает изменить условия проверок и сделать чужой код не работоспособным. В случае с юнит-тестами я сразу же получу красную лампочку. В случае с asserts это будет головной болью того, чей код перестанет работать. И, кстати, он может поменять спорный assert назад и сделать это моей проблемой и так до бесконечности.

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

P>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Любая функция в некоторой области либо регулярна, либо не регулярна; определена или не определена; вычислима или не вычислима. Вы говорите что представления у нас о ней нет, это означает что мы должны думать о ней самое худшее. А раз так, то она может возвращать кроме чисел еще и nonNumber, plusInfinity, minusInfinity. До кучи, пусть она еще возвращает значение nonCalculable — нельзя вычислить.

P>Вообще-то в таких случаях исключительную ситуацию создает аппаратура.
P>Я молчу о том, что вычисления компьютерные чуточку отличаются от вычислений на бумаге, и какая-нибудь бяка вполне может выскочить на ровном месте.
Да дело то не в том, что бяка может выскочить на неровном месте, а в том, что реальное программирование всегда происходит в режиме недостаточной информации. Сегодня мы были полностью уверены в том, что функция возвращает только числа, и полностью определена на всем интервале. А завтра прибежал заказчик и сказал, что под "полностью определена на всем интервале" он имел в виду "кроме, быть может, счетного множества точек".
Я уже говорил, что параноидальное программирование вредно. Потому что вместо написания

s = 0;
foreach(x in xRange)
  foreach(y in yRange(x))
    { 
     s+= f(x)*f(y);
    }
return s;

мы вынуждены писать

  foreach(x in xRange)
      foreach(y in yRange(x))
        { 
            X = f(x);
            if (X == nonNumber) 
                return nonNumber;
            Y = f(y);
            if (Y == nonNumber) 
                return nonNumber;
            XY = X*Y;
            if (XY == infinity)
              return infinity;
            s+=XY;
            if (s == infinity)
              return infinity
        }
    }

Это я еще простое выражение взял. А если бы там было что-то типа f(x, y)*g(x) + f(y, x)*f(x, y)+g(y)/g(x*y), то можно было б просто удавиться от всех этих ветвлений.

На самом деле ситуация еще хуже — даже если мы параноидально предположили, что функция может возвращать infinity и nonNumber помимо нормальных чисел, совершенно не факт, что заказчику завтра не захочется отличать plusInfinity от minusInfinity. И все эти требования невозможно заранее зафиксировать. Но академическое программирование чуждо этих нелепых подробностей — в нем на построение программы отводится бесконечное время, потому что цена ресурсов равна нулю. Бесплатные студенты потратят 0 рублей на написание как 100 строк, так и 1000.

eao197 wrote:

> Т.е., проблемы те же. И даже способы решения приблизительно одинаковые
> (в Ruby даже, имхо, способы создания ScodeGuard-ов попроще). Но вот не
> говорят в Ruby о безопасности исключений и базовые/сильные гарантии
> (да и здесь .NET-приверженцы от этом не упоминают). Почему?

На Ruby обычно, в основном, скрипты пишут. Ну а там упадет — и ладно. В
C#/Java в десктопных приложениях тоже такой же подход, в основном.

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

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, srggal, Вы писали:

S>>
S>>Сколько return должно быть в функции? Один или несколько ?
S>>

СГ>А что здесь есть кто-то утверждающий полезность единственности точки выхода из процедуры?

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

К Вашему сведению, забор из if только усложняет чтение программы, возникает мешанина кода обрабатывающего ошибки, и кода логики.
Уже наверное писали(тут писали много и правильно), что исключения кроме всего прочего, позволяют локализовать обработку ошибок в одном месте.

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

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

IT>Лучший способ борьбы с инвариантами — это не асёрты, а изничтожение самих инвариантов, чем их меньше, тем меньше проблем. Но это мы сейчас опять скатимся во флейм stateless vs stateful.

IT>Юнит тесты vs asserts обладают одним существеным преимуществом. Они доказывают, что сделанные изменения не нарушили работоспособность системы. В случае с асёртами мне никто не запрещает изменить условия проверок и сделать чужой код не работоспособным. В случае с юнит-тестами я сразу же получу красную лампочку. В случае с asserts это будет головной болью того, чей код перестанет работать. И, кстати, он может поменять спорный assert назад и сделать это моей проблемой и так до бесконечности.
Ну, мне лично кажется, что ассерты никак не мешают юнит тестам. Как и наоборот.

Зато ассерты без юнит тестов стоят ровно нуль. Потому, что ассерт — это императивная конструкция. Т.е. пока мы не наступили на ассерт, он абсолютно бесполезен. Наступанием на все граничные точки как раз и занимаются юнит тесты.
Ассерты помогут выяснить места косяков — когда падает юнит тест, вообще говоря не очень понятно, кто из стека был неправ. То ли DB, которая не смогла правильно обработать NULL, то ли BL, который этот нулл туда передал, то ли UI, который этот null позволил ввести.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Я делю ошибки на две категории:
СГ>1) ошибки в данных (программа на вход получила неправильные данные);
СГ>2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).

СГ>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.

Писать функции, возвращающие код ошибки? Иногда так и стоит делать, но за правило я бы это ни в коем случае не брал.

СГ>Ошибки категории (2) фатальные, тут программу надо завершать — в программе ошибка, т.е. программа не правильная. Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Nickolay Ch, Вы писали:

СГ>http://www.rsdn.ru/Forum/Message.aspx?mid=1496415&amp;only=1

Автор: Nickolay Ch
Дата: 19.11.05

NC>>А вот очень бы хотелось услышать, что вы предлагаете на замену эксепшенов, только мб в новой теме. Они много чем не нравятся, но пока не видно лучших механизмов обработки ошибок.

СГ>Я делю ошибки на две категории:
СГ>1) ошибки в данных (программа на вход получила неправильные данные);
СГ>2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).

СГ>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.
СГ>Ошибки категории (2) фатальные, тут программу надо завершать — в программе ошибка, т.е. программа не правильная. Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.

Посыл неверный.
Пример: некий оффлайн клиент. Пользователь отредактировал документ и хочет его скинуть на сервер. Сервер недоступен. Какая это ошибка в вашей терминологии? На 1ую непохоже, а во втором случае надо завершить программу? И все, что было создано пропадет?
Аналогично с сохранением файла на носитель, на котором кончилось место. По идее надо дать возможность сменить носитель и т.д., а не молча закрыть прогу.
Опять возвращаемся к кодам ошибок или исключениям.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>для домашнего компьютера — исключение, ошибка, что надо сделать с домашним компьютером? — Выключить и поменять блок памяти вручную.

А что программе-то делать в этих условиях?

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

CS>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Я делю ошибки на две категории:

CS>Изначальный посыл неправильный.

CS>исключительная ситуация это есть нечто ожидаемое но исключительное.
Точно, и в обекте эксепшена может содержаться дополнительная информация о ситуации.

Например, в текстовом редакторе вы переводите каретку на строку вверх. Допустим, этим занимается отдельный метод, который возвращает номер новой текущей строки. А строчка вверху короче и поэтому каретка также будет смещена по колонкам. В этом случае метод бросает исключение, в котором содержатся новые координаты каретки.

То есть, мы хотели изменить Y-координату каретки, но также изменилась и X-координата — это не ошибка, это исключительная ситуация.

Сергей Губанов wrote:

> S>Вот в приведенном примере — что делать, если журнал не смог записать
> успешную запись в файл?
> Что делать кому? Объекту "ЛокальныйСчёт" по этому поводу точно делать
> ни чего не надо, он свою задачу выполнил на 100%, а уж как там внутри
> объекта "Журнал" чего-то стряслось — не его дело.

Нет, это как раз его дело. Так как он должен откатить транзакцию и
передать "выше" сообщение об ошибке.

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

> Ничего подобного.
> 1) Не все процедуры обязаны возвращать булевый признак успешности.
> Например, операция рапорта о чём-то произошедшем, ничего не должна
> возвращать — это никому не интересно кроме неё самой.

Да? А может быть это интересно вызывающему коду. Например,

class Reporter
{
public:
    virtual void report(...)=0;
};

void отдать_кучу_бабок(Reporter *reporter, ...)
{
    //переводим кучу бабок
    reporter->report(отчет_о_переводе_кучи_бабок);
}

Заметим, что код функции "отдать_кучу_бабок", реализации интерфейса
"Reporter" и код, вызывающий функцию "отдать_кучу_бабок", может
находиться в разных местах (в разных модулях, например). Более того,
функция "отдать_кучу_бабок" ничего не знает о "важности" функции
"report" — там может быть и просто запись в лог-файл, а может быть и
отсылка важного письма в налоговую при размере транзакции больше
определенного.

Теперь, у нас в функции "report" произошло катастрофическое событие — но
на ход работы функции "отдать_кучу_бабок" это никак не повлияет. Что
делать?

Конечно, поставить для функции report возвращаемое значение типа
"успех/неуспех".

class Reporter
{
public:
    bool void report(...)=0;
};

bool отдать_кучу_бабок(Reporter *reporter, ...)
{
    //переводим кучу бабок
    if (!reporter->report(отчет_о_переводе_кучи_бабок)) return false;
    ...
    return true;
}

Но от кода возврата нам мало толку — надо как-то передать более
осмысленную информацию. Решение, казалось бы, простое — делаем в классе
Reporter поле error:

class Reporter
{
public:
    Error *error;
    bool void report(...)=0;
};

bool отдать_кучу_бабок(Reporter *reporter, ...)
{
    //переводим кучу бабок
    if (!reporter->report(отчет_о_переводе_кучи_бабок))
    {
        //Откатить транзакцию, выполнить cleanup
        return false;
    }
    ...
    return true;
}

Но опять проблема, теперь класс Reporter нельзя использовать в
реентерабельном или многопоточном коде. Значит, нужно передавать еще
один контекст для ошибок, параллельно с классом Reporter.

class Reporter
{
public:
    bool void report(...)=0;
};

class ErrorContext
{
public:
        Error *error;
};

bool отдать_кучу_бабок(Reporter *reporter, ErrorContext *ctx,...)
{
    //переводим кучу бабок
    if (!reporter->report(отчет_о_переводе_кучи_бабок))
    {
        //Откатить транзакцию, выполнить cleanup
        return false;
    }
    ...
    return true;
}

Теперь осталось написать вызывающий код:

...
ErrorContext ctx;
Reporter *rep = .... ;
отдать_кучу_бабок(rep,&ctx,....);

if (ctx.error) //Случилась беда?
{
    //Да, все плохо :(
    if (std::typeid(ctx.error)==std::typeif(ErrorEmailFailed))
       //Делаем MessageBox с сообщением "не удалось послать письмо"
    else if (std::typeid(ctx.error)==std::typeif(ErrorDiskFull))
       //....
}
...

Теперь осталось посмотреть на это все пристальным взглядом....

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Тогда надо использовать другой базис примитивных операций. Ибо в выбранном базисе состоящей всего из одной примитивной операции "Начислить":

СГ>PROCEDURE (this: СчётВУдалённомБанке) Начислить* (сумма: Деньги; откого: ОтКого; VAR err: Errors.List): BOOLEAN, NEW, ABSTRACT;

СГ>после свершившегося начисления, откат назад невозможен.

Да уж... Видимо, действительно только C++ники дошли пока до таких понятий, как "базовая гарантия безопасности исключений" и "сильная гарантия безопасности исключений".

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

E>Причем не важно, сигнализирует ли исключение об ошибке, исключительной ситуации или же исключения используются для реализации логики (бывают и такие ситуации, когда исключения удобнее чем if/elseif/else или switch/case).

Яркий пример — разбор ХМЛя многими библиотеками. Обычно достаточно знать, что ХМЛ невалидный и сразу завершить работу:

Например, кусок:

bool displayReservationCommand::execute()
{
    QDomDocument xmlDoc;
    xmlDoc.setContent(_params["data"]);

    QDomElement el = xmlDoc.documentElement();
    if(!el.isNull())
    {
        el = el.firstChild().toElement();
        if(!el.isNull())
        {
                QString str;
                QTextStream ts(str, IO_WriteOnly);

                el.save(ts, 0);
                QString attr = el.attribute("guid", "-1");
                iqAdrReservationApplicationForm::displayReservation(attr, str);
                
                return true;
        }
        
        return false;
    }

    return false;
}

В процессе эксплуатации оказалось, что ХМЛ в 99% случаев приходит валидный (так как я сам его и отсылаю ). Вопрос. Нафига мне там столько if-ов? Когда документ начинает расти, код читать становится неприятно.

int displayReservationCommand::execute()
{
    QDomDocument xmlDoc;
    xmlDoc.setContent(_params["data"]);
    
    try{
        QDomElement el = xmlDoc.documentElement();
        el = el.firstChild().toElement();
        
        QString str;
        QTextStream ts(str, IO_WriteOnly);
        el.save(ts, 0);
        
        QString attr = el.attribute("guid", "-1");
        iqAdrReservationApplicationForm::displayReservation(attr, str);
        
    }catch(... /*на самом деле здесь надо что-нить типа XMLTagError, но мне все равно.*/){
        return false; 
    }

    return true;
}

Сама функция возвращает application-specific error-code.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Я делю ошибки на две категории:
СГ>1) ошибки в данных (программа на вход получила неправильные данные);
СГ>2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).

СГ>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.
СГ>Ошибки категории (2) фатальные, тут программу надо завершать — в программе ошибка, т.е. программа не правильная. Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.

Дело в том, что при применении Вашего подходя, вызвавшего такую бурную дискуссию, разработчи сталкивается со следующим известным вопросом:


Сколько return должно быть в функции? Один или несколько ?


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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, akasoft, Вы писали:

СГ>>>А то ведь, можно и так:

СГ>>>PROCEDURE Move (VAR src, dst, sum: REAL): BOOLEAN;
СГ>>>BEGIN
СГ>>>  IF src >= sum THEN
СГ>>>    src := src - sum;
СГ>>>    dst := dst + sum;
СГ>>>...
СГ>>>

A>>Ага! И полюбому зачисляем на счёт-приёмник сумму. Здорово. Все бы так уже богачами были.

СГ>Напоминаю синтаксис инструкции IF языков Modula/Oberon/Component Pascal:

СГ>IF ... THEN ... END
СГ>IF ... THEN ... ELSE ... END
СГ>IF ... THEN ... ELSIF ... THEN ... END
СГ>IF ... THEN ... ELSIF ... THEN ... ELSIF ... THEN ... END
СГ>...

СГ>т.е. в конце инструкции стоит END

А вот и нет в паскале только 1 оператор в модуле тоже
нужно писать BEGIN END
ві наверное на VB перепрограммировали.

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

M>Яркий пример — разбор ХМЛя многими библиотеками. Обычно достаточно знать, что ХМЛ невалидный и сразу завершить работу:

M>Например, кусок:

А если так?

bool displayReservationCommand::execute()
{
    QDomDocument xmlDoc;
    xmlDoc.setContent(_params["data"]);

    QDomElement el = xmlDoc.documentElement();
    if(el.isNull()) return false;

    el = el.firstChild().toElement();
    if(el.isNull()) return false;

    QString str;
    QTextStream ts(str, IO_WriteOnly);

    el.save(ts, 0);
    QString attr = el.attribute("guid", "-1");
    iqAdrReservationApplicationForm::displayReservation(attr, str);
    
    return true;
}

Исключений нет, а кода даже на две строчки меньше чем у тебя

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

[]

R>Все гораздо проще. Есть, предположим, спецификация, вида:

R>

R>       | Positive if x > 0
R>f(x) = | Negative if x < 0
R>       | Zero otherwise 
R>

R>Не может быть спецификации без _полной_ проверки возможных значений.
R>И, строго говоря, код вида:
R>

R>int f (int x) {
R>    if (x > 0) return 1;
R>    if (x < 0) return -1;
R>    return 0;
R>}
R>

R>Ей формально не соответствует. И главное, что проверить это очень сложно. В общем виде такое вообще не проверяется.

Если этот код формально не соответствует той спецификации, то видимо он формально соответствует некой другой спецификации. Можно взглянуть на нее?

R>А когда таких вариантов много, то непредсказуемость растет очень быстро.
R>тогда как код вида:
R>

R>int f (int x) {
R>    if (x > 0) return 1;
R>    else if (x < 0) return -1;
R>    else return 0;
R>}
R>

R>Вполне соответствует. Проверяются все значения и для любого варианта есть выход. То есть можно показать, что эта функция соответствует спецификации. Речь формально уже не идет о множественном выходе.

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

[]

reductor,

> V> Например, в С++, опять ресурсы и коды возвратов:

> Ну если дело только в этом конкретном коде, то:
>

>      if (error( openRes1() )) return ERR_RESOURCE1;
> else if (error( openRes2() )) return ERR_RESOURCE2;
> else if (error( openRes3() )) return ERR_RESOURCE3;
> else return ERR_SUCCESS;
>

> формальнее некуда
>

Здесь упущена существенная деталь, присутствовавшая в оригинальном варианте: освобождение ресурсов в каждом из случаев (в оригинале это делали деструкторы).

Здравствуйте, Сергей Губанов, Вы писали:

СГ>На самом деле, применительно к доводам использования exception, я привёл (мою) классификацию ошибок: (1) ошибка в данных, и (2) ошибка в программе. Сказал что для обработки ошибок в данных exception не нужны, а для обработки ошибок в программе довольно ASSERT + system trap, так что опять exception не нужны. Вы против этого что-то имеете конструктивно возразить?

Да нет такого разделения. Простой пример "в лоб".

Процедура А подразумевает, что ей никто не передаст null в качестве аргумента. Согласно твоей классификации, если мы подали туда null, то это — ошибка программы.

Процедура B читает некие данные в определенном формате. В процессе работы вызвает процедуру C для преобразования данных. Результат преобразования данных помещает как аргумент вызова процедуры A. Известно, что процедура С не возвращает null (достаточно оттестирована).

Однако, в формате данных произошел сбой, процедура С в нештатной ситуации (отсутствующей в тест-кейсах) выдала null, результат поместили как аргумент в А.

Какому классу принадлежит ошибка?


----------
ИМХО, ошибки могут принадлежать только одному классу — ошибки программы. Ошибка данных — это нонсенс. Входные данные по определению могут быть произвольными. Если кто-то считает и пишет свое ПО для работы "в специальных условиях", в расчете на "специальные данные", то он нарушает самые основы, и регулярно получает по голове обычно.


----------

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

IT>Так может такие проверки должны быть штатными и использоваться не только в режиме отладки?
Зачем, если они срабатывают только при наличии ошибки в программе (и теоретически в окончательной версии их быть не должно) и могут снижать производительность?

IT wrote:

> C>Или, например, вот такой код (спас часы отладки):
> Так может такие проверки должны быть штатными и использоваться не
> только в режиме отладки?

А зачем? assert показывает ошибки программиста, а не пользователя. То
есть ни при каком варианте работы событий пользователь не должен его
получить, а значит и включать его не надо.

В рельной жизни assert'ы обычно оставляют в бэта-версиях, и выкидывают в
релизах.

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

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

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

V>Таким образом, верификация даже такого кода может быть полной.
Погоди, верификация и корректность работы компилятора — не одно и то же. Язык просто даёт нам некие автоматически работающие механизмы и не более того. И там и там есть оговорки использования и т.п. Можно и в деструкторе RAII исключение пульнуть.

Другое дело, что верификация невозможна без спецификации, которой должна соответствовать программа. Нет спецификации — верификация невозможна. Вывал AV в некоторых ситуациях может расцениваться как штатное и запланированное поведение. То есть, сначала нужна полная спецификация: что можно, чего нельзя и т.п. Но такая спецификация по сложности сопоставима с самой программой, то есть, получим ту же проблему, но в профиль: языки спецификации, наследование спецификаций (множественное vs одиночное), синтаксический оверхед при специфицировании поведения и т.п.

V> Другое дело, что мы не сможем верифицировать отдельно взятый участок (вернее можем, поясню далее), т.е. необходимо больше информации, о том, что происходит "неявно" для случая С++.

Да ну? А что, в случае Java/C# работа GC уже стала 100% детерминированной? А полиморфный код тоже 100% сможем верифицировать?

V>Однако, и здесь нас ожидают бенефиты. Мы можем построить верификацию кода иерархически, т.е. проверифицировать сначала "прочистку", а затем код, использующий ее неявный вызов. Ввиду того, что целевой код неплохо сокращается в случае множественного return (или использования exceptions как продвинутой разновидности), мы можем получить как раз больше возможностей для верификации на "реальных объемах".

Не, гиблая затея на любых объёмах. Примерно такое же ожидание панацеи, как её в своё время ожидали от перехода к языкам высокого уровня. Просто проблемы сместятся с одного уровня на другой. Всё равно задач адекватного учёта внешних условий и построения точных формулировок никто не снимет.

Здравствуйте, Сергей Губанов

Самое время синтаксический оверхед померять

IT wrote:

> C>А зачем? assert показывает ошибки программиста, а не пользователя. То
> C>есть ни при каком варианте работы событий пользователь не должен его
> C>получить, а значит и включать его не надо.
> Для библиотечного кода эти проверки должны присутствовать и как
> правило присутствуют, загляни хотя бы в исходники .NET FW.

Стоп. В FW куча проверок пост/пред-условий — это вполне нормально, если
клинет может передать неправильное значение. В случае FW клинетом
является пользовательское приложение.

Assertы нужны для проверки "невозможных" случаев, типа:

string str="adfhjadkjf";
string str2="adsfkjds";
string str3=str+str2;
assert(str3.size()!=0);

При нормальной работе оператора "+" срабатывание assert'а невозможно,
соответственно заменять его на exception — нет смысла.

Или так:

class fast_string
{
    void append(const string_base &_other)
    {
       assert(_begin!=_end); //Check invariant.
       ....
    }
};

В данном случае проверяется инвариант класса — существование хотя бы
одного символа (с кодом 0). Если он нарушен — то это уже ошибка
программиста библиотечного класса или побочный эффект какой-нибудь
глобальной ошибки.

> C>В рельной жизни assert'ы обычно оставляют в бэта-версиях, и
> выкидывают в релизах.
> В реальной жизни фича отладчика, о которой я говорил выше, позволяет
> отловить всё тоже самое и без всякого замусоривания кода макросами.

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

> В общем, в ASSERT похоже тоже можно относить к устаревшим средствам и
> правилам типа венгерки, SELECT* и единственного return.

НЕТ! Тогда стоит к устаревшим правилам отнести и хороший стиль
программирования. В конце концов, он в .NET не нужен....

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

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

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

R>>Компиляторы конечно пусть выполняют свою работу, но есть все же некоторое соответствие между количеством их работы и нашим пониманием того, что мы делаем.

IT>Ага, компиляторы оставлены в покое, это уже прогресс

R>>А так же между количеством их работы и умственным напряжением того человека, который будет читать наш код.

IT>Не хочешь переписать вот такой код без returns?

Ок. Только сразу предупреждаю, я вообще не знаю C# (как и .NET), потому пришлось msdn почитать.
Могут быть ошибки (как в оптимальности реализации, так и в понимании логики того, что здесь происходит), но в общем вроде все так.

private static MemberMapper MapperFromTC (TypeCode tc) {
    MemberMapper value;
    switch (tc) {
        case TypeCode.SByte: value = new NullableSByteMapper(); break;
        case TypeCode.Int16: value = new NullableInt16Mapper(); break;
        case TypeCode.Int32: value = new NullableInt32Mapper(); break;
        case TypeCode.Int64: value = new NullableInt64Mapper(); break;
        case TypeCode.Byte: value = new NullableByteMapper(); break;
        case TypeCode.UInt16: value = new NullableUInt16Mapper(); break;
        case TypeCode.UInt32: value = new NullableUInt32Mapper(); break;
        case TypeCode.UInt64: value = new NullableUInt64Mapper(); break;
        case TypeCode.Char: value = new NullableCharMapper(); break;
        case TypeCode.Single: value = new NullableSingleMapper(); break;
        case TypeCode.Boolean: value = new NullableBooleanMapper(); break;
        case TypeCode.Double: value = new NullableDoubleMapper(); break;
        case TypeCode.DateTime: value = new NullableDateTimeMapper(); break;
        case TypeCode.Decimal: value = new NullableDecimalMapper(); break;
        case TypeCode.Guid: value = new NullableGuidMapper(); break;
        default: value = null; break;
    }
    return value;
}

private static MemberMapper GetNullableMemberMapper(MapMemberInfo mi) {
    Type type = mi.MemberAccessor.Type;
    MemberMapper value;
    
    if (type.IsGenericType == true && mi.MapValues == null) {
        Type underlyingType = Nullable.GetUnderlyingType(type);
        if (underlyingType != null) {
            value = MapperFromTC(underlyingType.IsEnum
                    ? underlyingType.GetTypeCode()
                    : Type.GetTypeCode(underlyingType)); 
        } else {
            value = null;
        }
    } else {
        value = null;
    }
    return value;
}

Если интересен был proof-of-concept, то вот. Ничего, что я добавил "лишнюю" функцию? а то читать было сложновато.
В общем-то в case-ах и if'ах можно было и return'ы оставить (вариантов без них не остается), но чтобы лишнего флейма избежать, я сделал с переменной.
Хотя идеально бы конечно было, если бы switch возвращал значение. Но так зато можно дополнительно в выводить в лог mm перед каждым возвратом. и то хлеб. Надеюсь, больше на C# ничего делать не придется.

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

Вот у тебя очень показательная ошибка. Надо писать так:

goto ошибка_снять;
...
goto ошибка_положить;
...
goto ошибка_журналировать;

а последний кусок вообще надо в обратном порядке:

ошибка_журналировать:
    rollback(&бо_журнализовать);
ошибка_положить:
    rollback(&бо_положить);
ошибка_снять:
    rollback(&бо_снять);
    return false;

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


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

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

IT>Здравствуйте, Глеб Алексеев, Вы писали:

ГА>>Избежать-то всегда можно. Вот и избегают некоторые фанатичные последователи этого правила, выходя из цикла 3-го уровня вложенности с помощью булевских флагов или даже бросая исключения .

IT>Совершенно верно. Это правило было актуально 15 лет назад. Сегодня оно является таким же устаревшим как венгерка и SELECT*.

Устарело?
Что, разобрались с остановкой тьюринг-полного автомата?
научились писать после этого статические анализаторы, которые находят и предсказывают поведение GOTO и множественного return?
Вырастили поколение суперлюдей, которые в состоянии смотрететь и тут же понимать что происходит, разбивая это в уме на подвыражения?
Наконец, уже написали компиляторы нормально это разруливающие и процессоры, у которых нет оверхеда от этого?

Хочу ссылки, выкладки и доказательства.

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

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

R>>Но конечно основной смысл в том, что если у нас есть
R>>

R>>// некий абстрактный код
R>>int y = 5;
R>>if (x == 1) return y;
R>>y++;
R>>if (x == 2) return y;
R>>return y + 5
R>>

R>>То понять что здесь происходит невозможно ни компилятору (та самая проблема с автоматами) ни человеку.

V>Я в очередной раз ловлю себя на ступоре после прочтения подобной фразы. Может я чего-то не понимаю? Откуда у компилятора или у человека сложности с прочтением? Насчет обязательности соответствия y<=f(x) мне понятно, насчет каких-то затруднений компиляции — нет. Хочешь, прямо здесь и сейчас граф детерминриованного автомата нарисую по этому куску кода? Не знаю, как другие программисты трассируют исходники в голове, но я, когда трассирую куски алгоритмов именно думаю как автомат — т.е. перехожу из состояние в состояние (состояние — множество значений всех локальных/глобальных переменных и проч. ячеек данных быстрой и медленной памяти, прямо или коссвено принимающих участие в алгоритме) в ответ на некие действия над этими переменными.

http://en.wikipedia.org/wiki/Halting_problem

Нужна функция, которая возьмет код другой функции и даст ответ — даст ли функция ответ в заданном диапазоне значений

Первое пришедшее в голову решение с построением графа (запуском, фактически) проблему не решает, функция может и не завершить свою работу — потому не завершит свою работу и наш анализатор — потому ответ мы так и не получим.
Анализировать построенный граф статически — тут для начала полезно вспомнить про поиск Hamilton Path и следующую из него NP-полноту

Причем, конечно, нет доказательства самого существования как проблемы остановки автомата, так и существования NP-полноты, причем, есть основания утверждать, что существование такого доказательства невозможно, так как его наличие автоматически означает решение самой проблемы остановки, что автоматически приводит нас к доказательству обратного. Корни этого тесно переплетаются с парадоксом Рассела и теоремой Геделя о неполноте, если вы знакомы с ними, то уже сами заметили это сходство парой строк раньше

V>Где фишка? Если можно построить детерминированный автомат, то можно проверифицировать что угодно.

Выше показано почему это не так

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

СГ>>А то ведь, можно и так:

СГ>>PROCEDURE Move (VAR src, dst, sum: REAL): BOOLEAN;
СГ>>BEGIN
СГ>>  IF src >= sum THEN
СГ>>    src := src - sum;
СГ>>    dst := dst + sum;
СГ>>...
СГ>>

A>Ага! И полюбому зачисляем на счёт-приёмник сумму. Здорово. Все бы так уже богачами были.

Напоминаю синтаксис инструкции IF языков Modula/Oberon/Component Pascal:

IF ... THEN ... END
IF ... THEN ... ELSE ... END
IF ... THEN ... ELSIF ... THEN ... END
IF ... THEN ... ELSIF ... THEN ... ELSIF ... THEN ... END
...

т.е. в конце инструкции стоит END

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

E>Спецификация исключений -- это только одна сторона медали.
E>Другая сторона -- это catch(...) или catch( const std::exception & ), ибо в противном случае игнорирования не получится -- исполнение прервется.
Исполнение прервется, если исключение будет брошено. В этом случае непойманные исключения действительно проявляются заметнее проигнорированных кодов возврата. Проблема в тех исключениях, которые не будут брошены при тестировании.

Я, видимо, недостаточно ясно сформулировал. Имелось в виду следующее:

///foo.cpp
void foo() {
  if ( judgement_day_has_come() ) {
    throw std::runtime_error("Приехали...");
  }
}

///bar.cpp
void bar() {
  foo(); // автор bar() плохо читал документацию/документации не было/забыл/ваш вариант,
         // но обработки исключения нет. Код компилируется и будет работать до самого Судного дня.
         // Как видим, игнорировать исключения очень даже можно, по-крайней мере, в С++
}

// а теперь то же самое с кодами возврата
enum status {
  status_ok,
  status_failure
};
status foo() {
  if ( judgement_day_has_come() ) {
    return status_failure;
  }
  return status_ok;
}

///bar.cpp
void bar() {
  foo(); // чем отличается клиентский код в случае игнорирования ошибки? ничем. 
}

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

Здравствуйте, Sergey J. A., Вы писали:

E>>Я думаю, тебе интересно будет почитать мнение Бертрана Мейера про исключения: Re[4]: Что вы предлагаете на замену эксепшенов?

Автор: iZEN
Дата: 22.11.05

Так вот Мейер в качестве одной из дисциплин обработки исключений определяет "Повторение" (Retrying), но об этом чуть ниже.
SJA>Жаль, но там нет ссылки на онлайн версию... В наших магазинах я такой книги не видал.

Re[4]: Что вы предлагаете на замену эксепшенов?

Автор: EvilChild
Дата: 22.11.05

Единственно, что Мейер об исключениях говорит со своей колокольни, поэтому мне показалось, что у Страуструпа про исключения лучше написано. Лаконичнее, практичнее и ближе к мейнстримовым языкам (C++, Java, C#).

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

R>Вообще непонятно почему все так против использования иксепшенов для описания логики, когда в большинстве рассматриваемых тут языков это самый быстрый и простой способ эмуляции pattern matching (не знаю как это по-русски), (чего о тех же классах с коллбеками по ним не скажешь).

У меня есть как минимум две причины.
Первая — эксепшены довольно тормозная вещь. В данном примере при перемещении коретки пользователем это вряд ли будет заметно. Но программист использующий подобный паттерн легко напишет и серверную логику на эксепшинах. А чё?
Вторая. Современные средства отладки сегодня позволяют практически отказаться от пошагового брождения по программе с целью локализации места ошибки. При возникновении исключения — отладчик автоматически останавливается в нужном месте. Время фикса багов в таком случае возрастает на порядки. Использование исключений где попало, особенно в циклически повторяющемся коде убивает всю идею. И приходится опять отлаживать код по старинке, с точками останова, бесконечными заходами и выходами во все возможные методы в программе.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Во-первых, и в главных, не "Ну-ка"-йте тут. Что ещё за моду взяли.

Сергей, это дружественная форма общения. Мы тут давно знаем, кто такой Антон, кто ты, тесный круг общения позволяет между собой иногда отбрасывать условности реального мира. Эта фраза — не оскорбление, это эмоциональный заряд. Поверь, как бы мы не спорили о "всём сущем", к тебе как личности отношение самое дружественное.

СГ>А то ведь, можно и так:

СГ>PROCEDURE Move (VAR src, dst, sum: REAL): BOOLEAN;
СГ>BEGIN
СГ>  IF src >= sum THEN
СГ>    src := src - sum;
СГ>    dst := dst + sum;
СГ>...
СГ>

Ага! И полюбому зачисляем на счёт-приёмник сумму. Здорово. Все бы так уже богачами были.

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

C>так как приложение в ответ на него
C>может удалить часть данных (почистить кэши, например)

Сдаётся мне, что нужно такие объекты держать как Weak Reference, а не чистить по исключению.

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

V>Процедура А подразумевает, что ей никто не передаст null в качестве аргумента. Согласно твоей классификации, если мы подали туда null, то это — ошибка программы.

Да, именно так.

V>Процедура B читает некие данные в определенном формате. В процессе работы вызвает процедуру C для преобразования данных. Результат преобразования данных помещает как аргумент вызова процедуры A. Известно, что процедура С не возвращает null (достаточно оттестирована).

V>Однако, в формате данных произошел сбой, процедура С в нештатной ситуации (отсутствующей в тест-кейсах) выдала null, результат поместили как аргумент в А.

V>Какому классу принадлежит ошибка?

Вы же сами написали, что "в формате данных произошел сбой" значит, во-первых, есть ошибка во входных данных. Во-вторых, если процедура B этого не поняла, значит в процедуре B есть програмная ошибка. Итого, здесь присутствуют оба типа ошибок.

V>ИМХО, ошибки могут принадлежать только одному классу — ошибки программы. Ошибка данных — это нонсенс.

Не ошибка данных, а ошибка в данных. Пользователь вводит число с клавиатуры и нажал не на ту кнопку, ввел строку не представляющую число. Эта строка пошла на вход процедуры В. Процедура В поняла, что в данных поступивших к ней на вход есть ошибка и не стала вызывать процедуру-форматтер С, а вместо этого инициализировала процесс, в результате которого пользователь был ткнут носом в неправильно введённую им строку. То есть в программе ошибок нет, ошибка была в данных.

IT wrote:

> C>Assertы нужны для проверки "невозможных" случаев, типа:
> Это всё легко покрывается юнит-тестами. Или ты их заменяешь асёртами?

Уберите слово "легко"

> C>Ну да, просто заменить на замусоривание исключениями.
> Зачем? Предусловия в библиотечном или, например, в серверном коде
> проверять всё равно надо. А прикладной код нужно просто не лениться
> тестировать. В независимости от того используются асёрты или нет.

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

> C>НЕТ! Тогда стоит к устаревшим правилам отнести и хороший стиль
> программирования. В конце концов, он в .NET не нужен....
> Зачем передёргивать? Или ты хочешь сказать, что хороший стиль и асёрты
> — это синонимы?

Это реакция на слово "устаревший"

> ЗЫ. Не хочу с тобой продолжать бодаться, всё равно ни мне тебя, ни
> тебе меня похоже не переубедить. Скажу только, что лично я, никакой
> практической пользы от асёртов сегодня не вижу. Речь идёт о .NET/C#.
> Такое моё сугуболичное ИМХО.

В .NET сильно помогает то, что бибилиотека делает очень много проверок.
То есть то, что в С++ могло проскочить незамеченным здесь вызовет
исключение. Но это не отменяет ценности ассертов в своем коде

> Пойду лучше Серёгу за забытый ролбэк отстегаю

Бей его, бей

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

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

E>>А вообще, кроме классика Н.Вирта, есть еще и классик Б.Страуструп. В его книге "Язык программирования С++. 3-е издание" есть целая глава #14, которая посвящена обработке исключений. Тебе бы не мешало прочитать из нее хотя бы 14.1 (Обработка ошибок [except.error]) и 14.1.1 (Альтернативный взгляд на исключения [except.views]). Там очень сжато и точно описываются разные стратегии диагностики ошибок и роль в этом деле исключений.
E>>Note. Названия разделов я привел из англиского варианта книги, т.к. русский вариант у меня на работе.

ZEN>Ещё есть один классик т.н. "контрактоного программирования" (кстати, последователь Н.Вирта, сейчас работает в ETH) — Бертран Мейер, автор языка Eiffel.
ZEN>Стоит почитать и его.

Стоит, безусловно. А что именно? Если можно URL, т.к. у нас достать печатное издание крайне проблематично.

Я упомянул разделы 14.1 и 14.1.1 книги Страуструпа потому, что там описываются следующие стратегии поведения в случае возникновения ошибок:

• аварийное завершение программы;
  
• возврат значения, определяющего наличие ошибки;
  
• возврат корректного значения, но оставление программы в некорректном состоянии;
  
• вызов специально предоставленных функций для реакции на ошибки

и приводится сравнение этих вариантов с вариантом использования исключений.

Во многих случаях в C++ (да и не только), исключения являются единственным способом информирования приложения об ошибках. Например, при перегрузке операторов. Например, оператора << или +. На самом деле, как использовать коды ошибок вот в таком выражении:

db_stream << header << description << footer;

а ошибка возникает из-за отсутствия достаточного места на диске?

Ну и еще одно соображение. Исключения, в отличии от того же контрактного программирования, стали широко призанным и адаптированным механизмом. C++, Java, C#, Python, Ruby, Ada, Smalltalk -- везде есть исключения. Конечно, это не панацея от всех болезней, и применять их нужно осторожно. Тем не менее, вряд ли идея исключений получила бы такое широкое распространение, если бы она не была настолько удачной.

Существует множество вариантов

например, обработка через continuation passing — см. например, conditions в Common Lisp. И этот подход, нужно сказать, кроме того, что быстрее, чем иксепшены, еще и дает возможность поправить ошибку на месте — без раскрутки стека — и продолжить делать то же самое как ни в чем не бывало.
Так же, в строго-типизированых языках это могут контейнерные (higher order aka kinds) типы
еще довольно уникальный случай — в хаскеле некоторые библиотечные типы для обработки ошибок определены еще и как монады. например, Maybe. Хотя некоторые виды ошибок в хаскеле по-умолчанию предлагается отлавливать через некоторую симуляцию иксепшенов, которая впрочем чистой воды те же continuations + контейнерные типы.

Так что по обстоятельствам

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

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

Да, Вы правы. Я упустил этот вариант. Прошу прощения. Разумеется в этом случае системные ловушки (trap) обязательны.

Попытаюсь объяснить почему я упустил этот вариант из виду. Дело в том, что программирование в компонентных системах (скажем, таких как Оберон-системы) это уже есть де-факто написание плагинов для уже готовой системы времени исполнения. Каждый модуль (компонент системы) — фактически и есть плагин. Разумеется, если цель состоит в написании своей собственной системы времени исполнения, то, повторяюсь, системные ловушки обязательны. Но даже это еще не повод включать механизм исключений в язык. Проблема решается на уровне библиотек. Прекрасный пример — BlackBox, там системные trap-ы есть (на уровне модуля Kernel), но в самом языке Component Pascal, на котором написано ядро = система времени исполнения, механизма исключений нет.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Это так называемые "продолжаемые исключения". Работает в языках, не разрушающих стек во время поиска обработчика. Например в ST, CLOS.
Честно говоря такое есть и в C. Только не везде реализовано, зависит от платформы и очень тормозно. Но благодаря таким возвратам можно управлять виртуальными страницами.

С уважением, Gleb.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Единственное правильное использование ловли исключений — это чтобы в случае чего грамотно прибрать за собой.
Оставим в стороне "единственную правильность ловли исключений", это вопрос религиозный.
СГ>При наличии автоматической сборки мусора, прибрать за собой — гораздо менее актуальная задача.
Т.е. при наличии сборки мусора нарушенные инварианты программы менее вредны?

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

E>А вот по поводу безопасности исключений если задуматься, то вообще голова кругом пойдет. Мне, например, интересно. В C++ много говорится о гарантиях безопасности (ну там базовая гарантия, сильная гарантия). А в других языках с исключениями (в том же Ruby, к примеру) от этом не упоминают. Из-за чего, спрашивается? В языках с GC нет таких пагубных последствий от исключений? Или просто их community еще до таких серьезных вопросов не доросло?
Трудно ответить, крайне мало опыта в других языках. В С++-сообществе есть много горячих тем, которые практически никого больше не волнуют, вроде "у меня работает, но что скажет Стандарт" , исключения в деструкторах, умные указатели и т.д. Но обработка ошибок — проблема фундаментальная в любом языке, и если кого-то мало волнуют вопросы безопасности исключений, то это говорит или о низкой квалификации программиста, или о низкой стоимости сбоя в разрабатываемой системе.

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

СГ>>Я делю ошибки на две категории:
СГ>>1) ошибки в данных (программа на вход получила неправильные данные);
СГ>>2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).

СГ>>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто.

A>Писать функции, возвращающие код ошибки? Иногда так и стоит делать, но за правило я бы это ни в коем случае не брал.

Правильное решение известно

Автор: Andrei N.Sobchuck
Дата: 21.07.05

, но, увы, не везде применимо. Как по техническим, так и по синтаксическим причинам.

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

S>Такими, которые обеспечивают ACID. Т.е. снятие/положение денег — некая сложная, но атомарная операция. Не обязательно приводить их полный код. Можно пользоваться ими как черными ящиками.

Программа, я так понимаю, работает в банке со счета которого деньги снимаются.

  TYPE
    СчётВУдалённомБанке* = POINTER TO ABSTRACT RECORD END;

    ЛокальныйСчёт* = POINTER TO RECORD
      остаток: Деньги;
      журнал: Журнал; (* not NIL *)
      (* ... *)
    END;

    Журнал* = POINTER TO ABSTRACT RECORD END;


  PROCEDURE (this: СчётВУдалённомБанке) Зачислить* (сумма: Деньги; откуда: Откуда; причинаОтказа: Причина): BOOLEAN, NEW, ABSTRACT;

  PROCEDURE (this: Журнал) РапортОбУдачномОсуществленииДенежногоПеревода* (src: ЛокальныйСчёт; dst: СчётВУдалённомБанке; сумма: Деньги), NEW, ABSTRACT;
  PROCEDURE (this: Журнал) РапортОбОтказеУдалённогоБанкаНаЗачислениеДенег* (src: ЛокальныйСчёт; dst: СчётВУдалённомБанке; сумма: Деньги; причина: Причина), NEW, ABSTRACT;
  PROCEDURE (this: Журнал) РапортОНехваткеДенегНаСчётеДляОсуществленияДенежногоПеревода* (src: ЛокальныйСчёт; dst: СчётВУдалённомБанке; сумма: Деньги), NEW, ABSTRACT;


  PROCEDURE (this: ЛокальныйСчёт) ОсуществитьДенежныйПеревод* (счёт: СчётВУдалённомБанке; сумма: Деньги): BOOLEAN;
    VAR результат: BOOLEAN; причинаОтказа: Причина;
  BEGIN 
    результат := FALSE;
    IF (счёт # NIL) & (сумма > 0) THEN    
      this.НачалоЭксклюзивнойОперации;
      IF this.остаток >= сумма THEN
        IF счёт.Зачислить(сумма, this.ДеньгиОтМеня, причинаОтказа) THEN
          this.остаток := this.остаток - сумма;
          this.журнал.РапортОбУдачномОсуществленииДенежногоПеревода(this, счёт, сумма);
          результат := TRUE;
        ELSE
          this.журнал.РапортОбОтказеУдалённогоБанкаНаЗачислениеДенег(this, счёт, сумма, причинаОтказа)
        END
      ELSE
        this.журнал.РапортОНехваткеДенегНаСчётеДляОсуществленияДенежногоПеревода(this, счёт, сумма)
      END;
      this.КонецЭксклюзивнойОперации;
    END;
    RETURN результат
  END ОсуществитьДенежныйПеревод;

Запись в лог и отправку по e-mail делает объект Журнал.

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

P>Так ведь если запись в журнал транзакций не прошла, состояние объекта "ЛокальныйСчет" восстановить требуется. Кто этим займется?

Ага, а удалённый банк надо попросить: "Пожалуйста, верните деньги обратно"...

P>Кстати, в действительности там все намного сложнее.

Ясное дело.

Здравствуйте, Сергей Губанов, Вы писали:


СГ>Совершенно верно — не знает. Процедура чего-то сделала, о результатах сообщила. А при чём тут exception? Или exception — это единственный или лучший способ сообщить о результатах? Нет, не единственный и не лучший. Тогда при чём тут они...

Что не единственный — это да. А вот что не лучший — уже категорически нет.

Хотя бы потому, что с точки зрения ООД, функция должна возвращать результат своего выполнения. Например, строку. Что ей делать, столкнувшись с проблемой, не дающей ей вернуть строку?

Вообще, у вас фатальный баг в понятийном аппарате. Вы почему-то думаете, что исключения преднозначены для сообщений об ошибках. А это всего лишь побочный эффект от главного предназначения исключений. А именно:

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

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

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

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

M>Хотя бы потому, что с точки зрения ООД, функция должна возвращать результат своего выполнения. Например, строку. Что ей делать, столкнувшись с проблемой, не дающей ей вернуть строку?

Если заранее известно, что функция может сталкиваться с подобными проблемами, то это однозначно говорит о том, что функция не должна возвращать строку вовсе:

PROCEDURE TryReturnString (OUT s: String): BOOLEAN;

M>Вообще, у вас фатальный баг в понятийном аппарате...........Таким образом мы доказали, что исключения есть полезный и даже необходимый интсрумент при разработке программ.

Прикольное доказательство

Мой понятийный аппарат, говорит мне, что лучше писать так:

  IF TryReturnString(str) THEN 
    ... 
  ELSE 
    ... 
  END

чем вот так:

  bool valid = false;
  try
  {
    str = ReturnString();
    valid = true;
  }
  catch
  {
    ......
  }
  if (valid)
  {
     ........
  }

и я рассматриваю второй вариант как фатальный баг в понятийном аппарате.

S>1. Все функции обязаны возвращать булевый признак успешности выполнения.
S>2. Все функции обязаны передавать информацию о причине неудачи.
S>3. Если нам надо что-то большее, чем текст, в качестве информации о причине неудачи, то мы встряли. Потому что сигнатуры всех функций, имевших несчастье попасть в стек вызовов между тем местом, где мы обрабатываем ситуацию, и тем местом, где она произошла, должны быть модифицированы для передачи этой информации. Что-то более-менее общее мы использовать не сможем.

Мне это напоминает паскаль или COM с его HRESULT ;(

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

J>Это будет круче множественного наследования! Имхо повысит энтропию системы не в разы, а на порядки!

Ага, если обработчик:
1. Меняет состояние объектов, участвовавших в выполнении сбойнувшего фрагмента
2. Подшаманивает стек, чтобы все выглядело так, как будто все и было нормально с самого начала
3. Подправляет код методов в стеке, чтобы обеспечить более корректное исполнение.
4. Передает управление временно сгенерированному thunk, который модифицирует сам первоначальный обработчик, заканчивает очистку и продолжает выполнение в нормальном режиме.

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

CX>Вот такой вот практический опыт работы с исключениями, реализованными на уровне библиотеки.

Нужно добавить "... в С++".
Никто и не сомневался

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Посмотрите пожалуйста следующую статью (потрясающую воображение):
Ничего особенно потрясающего. Да, такую штуку можно реализовать для любого языка, который
а) поддерживает вложенные процедуры
б) поддерживает RTTI
в) разрешает библиотеке играть со стеком.
Кстати, вопрос с finally остался в статье неосвещенным, а очень зря. Дело в том, что на технике finally построено детерминистическое освобождение ресурсов (необходимое в системе без автоматических объектов).

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

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

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

P>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Пять процентов головного мозга — это конечно шутка. Понимать надо не в биологическом смысле, а в переносном

P>Тогда вопрос: сколько процентов головного мозга приходится напрягать физику-теоретику в повседневной деятельности? В каком угодно смысле. Просто для сравнения.

кандидату: 100% от нормы обычного человека, доктору: 500% — 1000% от нормы обычного человека академику, ну скажем, 20'000% от нормы....

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Необычно то, что:
СГ>1) Zero-overhead;
это маркетинг булшит. Никаким зеро там и не пахнет. Во-первых, для работы используются метаданные, которые конечно зеро по сравнению с "обычным обероном", т.к. встроены намертво, но вовсе не зеро по сравнению с полным отсутствием метаданных. Во-вторых, приведенные цифры по скорости раскрутки стека мягко говоря, далеки от зеро. Интуитивно мне кажется, что легендарно медленная раскрутка в плюсах порвет этот код как тузик грелку — потому что reflection да еще и с анализом стека на халяву не дается.
СГ>2) не требуется вносить изменения в синтаксис языка Оберон.
Это да. Удачное совпадение.
Кстати, нельзя ли поподробнее рассказать о том, каким именно способом эта библиотека подправляет stack pointer? Это основная фича данной техники, которая, к слову, никакого отношения к метапрограммированию не имеет — скорее к хакерству, а стало быть, под большим вопросом в средах, ориентированных на надежность.

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

B>Так и не все кандидаты могут стать программистами, ничего личного
Эт потому, что у мозгов кроме количественной характеристики есть ещё и тип. Тут приведение с трудом работает.

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

E>>Disclaimer. Сам именно таких приемов никогда не применял, но по жизни пару раз сталкивался с моментами, когда исключение выбрасывалось для изменения логики работы программы.

B>А вот это не есть хорошо, мухи от котлет должны быть отдельно, логика работы и логика обработки ошибок не одно и тоже.

"Исключение == ошибка" -- это догма, иногда вредная. Исключение -- это факт того, что что-то в программе идет не так, как ожидалось, но не обязательно из-за ошибки. Например, есть обработка транзакций от клиента. Одновременно может обрабатываться не более N транзакций, причем N довольно большое число и поросто так его не достичь (это возможно, например, в "часы пик" или когда транзакции начинают валиться после восстановления разрыва связи). Поэтому N+1 транзакции нужно корректно отказать со специфическим кодом возврата. Так же возможна ситуация, когда клиент повторяет транзакцию, не дождавшись от нас результата (не выдержал тайм-аут на своей стороне). Это так же не ошибка и повторый запрос нужно просто проигнорировать. И делается это приблизительно так:

try
    {
        // Нормальная обработка транзакции, расчитанная на обычные условия.
        ...
    }
catch( const too_much_trx_t & x )
    {
        // Обработка N+1 транзакции.
        ...
    }
catch( const repeated_trx_t & x )
    {
        // Обработка повторной транзакции.
        ...
    }
catch( const std::exception & x )
    {
        // А вот это уже действительно плохо!
        cleanup();
        initiate_shutdown();
    }

Ситуации, когда порождаются too_much_trx_t и repeated_trx_t -- это не ошибки, просто это исключительные ситуации для обычной обработки транзакций. Случаются они редко. А писать из-за них код в виде вложенных if-ов (как в первоначальном примере Mamut-а) -- получается плохочитабельно.

Здравствуйте, Глеб Алексеев, Вы писали:

ГА>Избежать-то всегда можно. Вот и избегают некоторые фанатичные последователи этого правила, выходя из цикла 3-го уровня вложенности с помощью булевских флагов или даже бросая исключения .

Совершенно верно. Это правило было актуально 15 лет назад. Сегодня оно является таким же устаревшим как венгерка и SELECT*.

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

E>Здравствуйте, Глеб Алексеев, Вы писали:

ГА>>Возвращаясь к исходному примеру, верхняя строчка будет короче в половине случаев, какое же это исключение?

ГА>>Использовать исключения не для обработки ошибок — это совершенно исключительная ситуация, должна продумываться и документироваться очень тщательно.

E>Не спорю. Но я здесь и сам примеры приводил:
E>Re[18]: Что вы предлагаете на замену эксепшенов?

Автор: eao197
Дата: 25.11.05

(это гипотетический пример),
E>Re[20]: Что вы предлагаете на замену эксепшенов?

Автор: eao197
Дата: 25.11.05

(это из реальной жизни, хотя и схематично, а не точно).


Пример с парсером вовсе не гипотетический. Более того, он еще давно имеет свое название в Computer Science — это Parser Combinators. Несколько ограниченный случай, но тем не менее, все равно очень мощное средство.

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

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

Все так на название чтоли остро реагируют...

Здравствуйте, Sergey J. A., Вы писали:

SJA>Не ошибки ? Ну, в таком случае отказ записи файла из за недостаточности места тоже не ошибка, а "исключительная ситуация для обычной обработки" файлов.

В некоторых ситуациях это может быть совсем не ошибка. Например, в системах со сборкой мусора недостаток памяти для размещения нового объекта -- это еще не ошибка, а повод к запуску GC. И только если после работы GC памяти не окажется, то это становится ошибкой.

Так же и с файлами.

Здравствуйте, Sergey J. A.

Сдается мне, что мы сейчас говорим об одном и том же, но разными словами.

Я думаю, тебе интересно будет почитать мнение Бертрана Мейера про исключения: Re[4]: Что вы предлагаете на замену эксепшенов?

Автор: iZEN
Дата: 22.11.05

Так вот Мейер в качестве одной из дисциплин обработки исключений определяет "Повторение" (Retrying), но об этом чуть ниже.

E>>Так же и с файлами.
SJA>Что то-же ? Не совсем понял...
SJA>С файлами представляю это так:
SJA>Если нет места на диске, но алгоритм расчитан так, что ищет место на других дисках и пробует сохранится туда — исключение не требуется (всё обрабатывается на одном уровне). Если уже нигде места нет — бросаем исключение — пусть кто знает обрабатывает.

Вот смотри, как я вижу себе это на примере log-файлов. Есть подсистема ведения логов, которая циклически использует, скажем, пять файлов для сохранения информации. При выполнении очередной операции записи может обнаружена нехватка места на диске. Тогда следует попробовать удалить один из старых файлов и попробовать произвести запись еще раз. Выглядеть это может так (на C++):

void store_log_record( const log_record_t & r )
    {
        while( true ) // Цикл вместо Мейеровского retry.
            {
                try
                    {
                        // Пытаемся сохранить запись.
                        try_store_record( r );
                        
                        // Т.к. исключений нет, то завершаем работу.
                        return;
                    }
                catch( const no_enough_space_t & x )
                    {
                        // Нет места, пытаемся освободить.
                        // Если процедура освобождения окажется неудачной, то она
                        // породит свое исключение, по которому мы вылетим из
                        // store_log_record.
                        try_free_space( x.spaced_needed() );
                    }
            }
    }

Т.е. получается, что исключение no_enough_space_t является фатальным для try_store_record() всегда, но не всегда является таковым для store_log_record(). А метод store_log_record() как раз использует мейеровскую дисциплину "Повторение".

SJA>Отсюда моё ИМХО: Исключение нужно бросать в том случае, если на данном логическом уровне (в данном модуле) неизвестен алгоритм работы с некоторой ситуацией. Которая и является исключительной на данном уровне.

Так ведь и я о том же. Но вот вернемся к моему исходному примеру.

void process_trx( const some_trx_t & trx )
    {
        try
            {
                // Нормальная обработка транзакции, расчитанная на обычные условия.
                // В этой функции неизвестно, как обрабатывать лишние и повторные
                // транзакции, поэтому там порождаются исключения.
                ordinal_processing( trx );
            }
        catch( const too_much_trx_t & x )
            {
                // Обработка N+1 транзакции.
                send_negative_response( trx, error_reason::too_much_trx );
            }
        catch( const repeated_trx_t & x )
            {
                // Обработка повторной транзакции.
                ignore_repeated_trx( trx );
            }
        catch( const std::exception & x )
            {
                // А вот это уже действительно плохо!
                cleanup();
                initiate_shutdown();
            }
    }

Т.е. уровень ordinal_processing() не может справится с ошибками too_much_trx и repeated_trx, поэтому он и порождает исключения. Но вот уровен process_trx как раз знает, как с этими ошибками бороться, и именно он инициирует их обработку. Т.е. в точности то, что ты и сказал (имхо).

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

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

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

R>>Вообще непонятно почему все так против использования иксепшенов для описания логики, когда в большинстве рассматриваемых тут языков это самый быстрый и простой способ эмуляции pattern matching (не знаю как это по-русски), (чего о тех же классах с коллбеками по ним не скажешь).

IT>У меня есть как минимум две причины.
IT>Первая — эксепшены довольно тормозная вещь. В данном примере при перемещении коретки пользователем это вряд ли будет заметно. Но программист использующий подобный паттерн легко напишет и серверную логику на эксепшинах. А чё?
IT>Вторая. Современные средства отладки сегодня позволяют практически отказаться от пошагового брождения по программе с целью локализации места ошибки. При возникновении исключения — отладчик автоматически останавливается в нужном месте. Время фикса багов в таком случае возрастает на порядки. Использование исключений где попало, особенно в циклически повторяющемся коде убивает всю идею. И приходится опять отлаживать код по старинке, с точками останова, бесконечными заходами и выходами во все возможные методы в программе.

Третье. Средство профилирования, способные перехватывать любые ошибки в коде, засыплят команду тестеров сообщениями, содержищие подчас бесполезную информацию.

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

C>reductor wrote:

>> Если чуть серьезнее, то логика — это штука немного формальная. Желание
>> джампнуть куда-нибудь (частным случаем чего кроме GOTO является и
>> множественный return), и сделать поведение программы непредсказуемым,
>> это не от большого понимания того, что сам делаешь.
>> А еще — это не религия и понятие "фанатизм" к ней не применимо. Люди
>> или могут обосновать свой вывод и выбор или нет.

C>Нет, это уже религия. Все нормальные программисты уже давно перестали
C>флеймить по поводу GOTO и структурного программирования, так как по
C>нынешним меркам это уже далеко не самый главный вопрос. Все
C>программисты, которых я знаю, думают примерно так: "GOTO это плохо?" —
C>"Плохо". "Структурное программирование хорошо?" — "Да". "Единый return,
C>выход из вложенных циклов по флагам, отсутствие break — оно надо?" — "А
C>нафига?"

Я не знаю что такое "нормальные программисты". Тем более что такое "все нормальные программисты".
Я знаю, что такое формальная логика и изоморфизм Карри-Говарда. А так же как я могу и как не могу обосновать, что мой модуль выполняет именно то, что он него ожидается при всех условиях.

Что касается выхода из циклов по флагам и отсутствия break, то вообще не понимаю в чем проблема — что мешает вынести цикл в отдельную функцию и выходить исключительно из цикла, делая код более предсказуемым?
return в цикле и множественный return — это вовсе не то же самое.

Я не очень хочу продолжать переливать из пустого в порожнее еще 1000 писем в мейлбоксе. Если у кого-то есть код и он может показать, что с множественным выходом (не путать с выходом из цикла и несколькими _условиями_ выхода) будет проще и обосновать и отладить и оно будет быстрее работать — прекрасно. А пока что это разговоры в пользу бедных. И шарлатанство.

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

R>Компиляторы конечно пусть выполняют свою работу, но есть все же некоторое соответствие между количеством их работы и нашим пониманием того, что мы делаем.

Ага, компиляторы оставлены в покое, это уже прогресс

R>А так же между количеством их работы и умственным напряжением того человека, который будет читать наш код.

Не хочешь переписать вот такой код без returns?

private static MemberMapper GetNullableMemberMapper(MapMemberInfo mi)
{
    Type type = mi.MemberAccessor.Type;

    if (type.IsGenericType == false || mi.MapValues != null)
        return null;

    Type underlyingType = Nullable.GetUnderlyingType(type);

    if (underlyingType == null)
        return null;

    if (underlyingType.IsEnum)
    {
        underlyingType = Enum.GetUnderlyingType(underlyingType);

        if (underlyingType == typeof(SByte))    return new NullableSByteMapper. Enum();
        if (underlyingType == typeof(Int16))    return new NullableInt16Mapper. Enum();
        if (underlyingType == typeof(Int32))    return new NullableInt32Mapper. Enum();
        if (underlyingType == typeof(Int64))    return new NullableInt64Mapper. Enum();
        if (underlyingType == typeof(Byte))     return new NullableByteMapper.  Enum();
        if (underlyingType == typeof(UInt16))   return new NullableUInt16Mapper.Enum();
        if (underlyingType == typeof(UInt32))   return new NullableUInt32Mapper.Enum();
        if (underlyingType == typeof(UInt64))   return new NullableUInt64Mapper.Enum();
    }
    else
    {
        if (underlyingType == typeof(SByte))    return new NullableSByteMapper();
        if (underlyingType == typeof(Int16))    return new NullableInt16Mapper();
        if (underlyingType == typeof(Int32))    return new NullableInt32Mapper();
        if (underlyingType == typeof(Int64))    return new NullableInt64Mapper();
        if (underlyingType == typeof(Byte))     return new NullableByteMapper();
        if (underlyingType == typeof(UInt16))   return new NullableUInt16Mapper();
        if (underlyingType == typeof(UInt32))   return new NullableUInt32Mapper();
        if (underlyingType == typeof(UInt64))   return new NullableUInt64Mapper();
        if (underlyingType == typeof(Char))     return new NullableCharMapper();
        if (underlyingType == typeof(Single))   return new NullableSingleMapper();
        if (underlyingType == typeof(Boolean))  return new NullableBooleanMapper();
        if (underlyingType == typeof(Double))   return new NullableDoubleMapper();
        if (underlyingType == typeof(DateTime)) return new NullableDateTimeMapper();
        if (underlyingType == typeof(Decimal))  return new NullableDecimalMapper();
        if (underlyingType == typeof(Guid))     return new NullableGuidMapper();
    }

    return null;
}

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

IT>>На плюсах и я таким частенько грешил На шарпе пока как-то надобности не было.
GZ>При отладке windows сервисов вставлял в код даже не assert, а прямой вызов дебаггера.

Это другой случай. При разработке UI иногда даже два монитора не помогают, если надо с фокусом повозиться, который постоянно уходит в отладчик. Приходится по старинке выводить всё что нужно в лог. Но это всё 5-10% случаев.

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

R>Создать свой Enum с необходимым набором?

Ну переедут if'ы в другое место. А в том месте делать return или через переменную?

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


R>Или я говорил, что код с несколькими стейтментами return не может работать корректно?
R>или что его нельзя в AST трансформировать во что-то там? Или что его нельзя скомпилировать?
R>Я утверждал, что без явной обработки всех условий вероятность ошибки и последующая с этим возня могут возрасти многократно.

Все с точностью до наоборот. В сочетании с RAII это помогает писать очень простой код. А надежность ПО достигается косвенным путем, а именно — чем проще код, тем сложнее ошибиться, тем легче сопровождать/исправлять и верифицировать.

Например, в С++, опять ресурсы и коды возвратов:

Resource1 res1 = openRes1();
if(error(res1)) return ERR_RESOURCE1;

Resource2 res2 = openRes2();
if(error(res2)) return ERR_RESOURCE2;

Resource3 res3 = openRes3();
if(error(res3)) return ERR_RESOURCE3;

return ERR_SUCCESS;

Теперь представь себе гору кода, если бы мы делал все через if-else и явное управление ресурсами... бррр... Вероятность ошибки возрасла бы многократно. Т.е., дело в том, что некое ELSE все равно выполняется. И разработчик, размеется, прекрасно знает — что именно (вызов деструкторов локальных объектов). И он это использует на всю катушку, для однократного программирования кода этих ELSE и затем многократного повторного использования (да и еще автоматического). Это тебе как бы затравка на другие способы повышения надежности (читабельность, максимальное повторное использование)

А с использованием exceptions, код выглядит еще читабельнее:

Resource1 res1 = openRes1();
Resource2 res2 = openRes2();
Resource3 res3 = openRes3();

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

IT>Вывести в чисто поле, поставить лицом к стенке и пустить пулю в лоб

... тремя очередями, чтоб всю жизнь помнил.

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

E>>Корректно работающий в соответствии со спецификацией код совсем не обязательно выполняет то, что предполагалось.

R>Корректно работающий в соответствии со спецификацией код, делает то, что предполагалось в спецификации с несколько большей вероятностью, чем код, который ей не соответствует. И есть формальный аппарат, позволяющий это проверить.
R>Если есть данные или другой аппарат, позволяющие это оспорить и доказать, что наоборот — буду рад услышать.

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

E>>Это эмпирический вывод, основывающийся на том, что:
E>>a) спецификации так же содержат ошибки;
E>>b) заказчик может не суметь четко описать свои пожелания и ожидания.
E>>Доказать я его не могу.

R>А вот это уже лирика, к делу не относящаяся. Методов, чтобы определить в каком состоянии писал заказчик спецификацию и писал ли вообще, а не сгенерировал генератором матерных слов, я не знаю. Себе спецификации я стараюсь писать сам. Формальные и без противоречий (это очень просто).

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

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

C>Не совсем так, но близко.

Т.е. на 10 строчек полезного кода столько же, если не больше, мусора. Найс.

C>Заодно помогает прояснять контракты использования.

У тебя же исходники есть, чего там прояснять.