Обработка «исключений», которые с высокой вероятностью становятся «ошибками»

Question

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

Я запутался в том, как предотвратить исключение из ошибки. Скажем, у меня есть модельный класс, который содержит множество отношений. Модель имеет метод Model.AddRelationship(), который может создать круговую ссылку в модели. Если пользователь пытается добавить отношение в пользовательском интерфейсе, который создает циклическую ссылку, ему необходимо заблокировать это и сообщить, почему. Поэтому я столкнулся с некоторыми вариантами, такими как:

// In the UI when the user tries to add a relationship:

var newRelationship:Relationship = new Relationship();

if(Model.AddingThisWillCreateACircularReference(newRelationship))
{
    this.warnUserAboutCircularReference();
}
else
{
    Model.AddRelationship(relationship);
}

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

// In the model itself:

public function AddRelationship(relationship:Relationship):Boolean
{
    var success:Boolean = true;

    if(this.AddingRelationshipWillCreateACircularReference(relationship))
    {
        success = false;
    }
    else
    {
        this.addRelationship(relationship);
    }

    return success;
}

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

Answer 1

По соглашению «ошибки» указывают на ситуации, которые приложение просто не может обработать или восстановить после него (например, сбой диска). Исключение составляют ненормальные ситуации, в которых приложение может попытаться восстановиться или даже очистить себя перед завершением работы.

Я считаю полезным разделить Исключения еще на два типа: бизнес-исключения, которые являются условиями, вызванными неправильной настройкой или неправильным обращением с приложением (т. Е. Исключения проверки), и техническое исключение, которые являются условиями, не вызванными самим приложением (т. Е. , потерянное соединение с базой данных, время ожидания сокета и т. д.).

Возвращаясь к вашему вопросу, вы правы: модель должна всегда быть последовательной, и ее следует применять на самом низком уровне, чтобы способствовать повторному использованию. Таким образом, поместите проверку в модель, попробуйте выполнить операцию и, если она не удастся, сообщите пользователю. Если у вас нет исключений в качестве встроенного механизма на вашем языке, я бы пошел до того, чтобы вернуть «код результата», указывающий результирующий статус операции (т. Е. 0 - Успех, 1 - Круговая зависимость, 2 - Неизвестный причина и т. д.).

Answer 2

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

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