[qt] каноническая обработка ошибок

Тут так и просится монада Maybe. Вот реализация на цпп :) http://kerneltrap.org/node/7488

Хотя оператор >>=, очевидно, ни к чему. Остаётся просто boost::variant в чистом виде.

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

Вместо Maybe можно использовать QSharedPointer.

QSharedPointer или QVariant. Лучше дополнить тип, чем создавать новый слот.

В хаскеле Maybe имеет два конструктора: Nothing и Just a, где a - любой тип. Т.е. значение типа Maybe или пустое, или хранит в себе значение нужного тебе типа. Ситуация похожа на передачу ссылки на объект: если указатель нулевой, то ничего не передано, иначе это указатель на объект.

boost::variant позволяет хранить в себе значение одного из двух типов. Для реализации Maybe созданы классы Nothing и Just, при получении значения типа Maybe проверяется, можно ли получить из него указатель на Nothing, и если нет - значит там хранится значение класса Just, иначе - ничего.

Кстати да, совсем забыл о такой возможности, спасибо. Только запутал топикстартера монадами :)

Как вариант, возвращать объект-пустышку. Что-то вроде того, как сделано в самом кутэ для некоторых классов, у которых есть метод isValid().

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

Кроме как создавать ещё один сигнал-слот (типа connect(B, error(QString), A, onError(QString)) ничего в голову не приходит.

И таки чем плох этот вариант?

>В Qt исключения использовать то можно

А вот и не всегда. Для QWS нельзя. И если писать код с учётом этой платформы, то видимо лучше обходиться без этого.

Странный вопрос:

можно через сигнал-слот; можно через вызов метода sender()-а можно через QApplication::postEvent() можно через указатель на A, который хранится где-нибудь еще итд

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

А по поводу эксепшенов: я обычно в объекте сразу создаю поле m_error, и если конструктор может повести себя неправильно, то заполняю этот m_error. После вызова делаю проверку пустая ли эта m_error, если да isValid() {return m_error.isEmpty()} - все ок; нет - сообщение об ошибке есть.

Ничем не плох. Я просто думал, что может ещё какие варианты есть. Судя по всему так и придётся делать, только в аргументы надо добавить где ошибка. К сигналу ведь много слотов может быть подкючено. Тогда «сигнализирующему» объекту надо знать в каком именно слоте ошибка. Но это уже так, детали. Сам к себе придираюсь.

Да, вы правы.

Я раньше тоже так делал. Но теперь придерживаюсь принципа «нет удачного вызова конструктора - нет объекта». Так логика проще получается. Иначе вам всё время надо будет этот m_error проверять.

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

программа обычно просто падает с сообщением об ошибке

А вы посмотрите на програму как на автомат конечных состояний. В случае описаном вами этот автомат переходит с состояние ошибки, но это состояние не запрограмировано. Если бы вы писали прошивку медицинского оборудования или автопилот для самолёта как бы вы написали?

тебя неправильно спроектировано взаимодействие объектов

Если бы у меня были лишь вызовы методов - то это не чем не отличалось бы от способа описного в первом абзаце темы. И вопроса бы и не возникало. А вопрос как раз в связке сигнал-слот. В доках пишут: это - сигналы, это - слоты. Коннект и... опа! - всё работает. А я спрашиваю как мне лучше уведомить «сигнализирующий» объект об ошибке в слоте? Или вообще стоит такое делать? Может существует другое решение?

если программист неправильно

опа. не вчитался.

тогда вопрос: програма создаёт объект, а он не создаётся. Например объект является соединением с www.linux.org.ru, а инета нет.

Как вы обработать эту ситуацию?

Я выброшу исключение, а в коде, который пытался это соединение создать, напишу try/catch. Думаю идея проста.

Как вы обработаете эту ситуацию?

//фикс

Да. У вас очень плохо с ООП.

Идеалогия сигналов/слотов не подразумевает ответа

Да, у меня плохо с ООП. Я и не претендую на то, что бы меня считали специалистом в этой области ;)

Ну а по делу есть что сказать?

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

Есть. Не использовать этот механиз в том случае, если могут возникнуть такие ошибки

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

Хорошо, я понял вашу точку зрения, спасибо.

Это достаточно распространения точка зрения на этот механизм.

А то, что вы хотите, этим авторизовываться не должно