[Большой Проект] Ядро проекта, гуй проекта и исключения.

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

namespace mycore
{
Class MyParser {
    // ...
    enum MyParseStatus {
        BadBracket,
        WrongSymbol,
        NoParseErrors
    }
    
    MyParseErrors parseFile(const QFile &file) {
        // ...
        // ...
        while(/*парсим файл*/) {
            // ...
            if(/*плохая скобочка*/) {
                return BadBracket;
            }
        }
        return NoParseErrors;
    }
};
}

namespace mygui
{
class MyParseGui
{
    // ...
    void tryToParse(const mycore::File &file) {
        // ...
        switch(myparser->parseFile(file)) {
        case NoParseErrors:
            // ...
            break;
        case BadBracket:
            // ...
            return;
        // прочие случаи...
        }
        // ...
    }
};
}

В итоге вопрос сводится к такому: как лучше делать — эксепшнами, как в моём велосипеде или как-то иначе?

может я что-то не так понял, но в таких случаях просто кидаю исключение, а в месте вызова, для гуя, отлавливаю его вместе с сообщением об ошибке и показываю «окошки» (с)

По умолчанию делайте на исключениях, они для того и предназначены.

Ваш велосипед чересчур велосипедный. Попробуйте Boost.Spirit.

если парсер более-менее сложный, то вы затрахаетесь передавать наверх код ошибки :)

Озвучу то, что сказал в джаббер (с целью критики моего мнения):

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

То есть throw'ить char[], так?

в ядре должна сделать систему логирования.
в системе завести атрибут аля «объект для логирования в пользовательском интерфейсе» и если возникает событие и объект не Null засылать в него сообщение.

в гуе должна быть подсистема, кот умеет понимать сообщения системы логирования, указатель на эту подсистему передавать системе логирования ядра в атрибут «объект для логирования в пользовательском интерфейсе»

ЕМНИП, такие фокусы запрещены стандартом. Унаследуйте от std::exception.

> в ядре должна сделать систему логирования.

великая русская языка.

наверное, если бы я писал что-то типа mdp, то так бы и сделал, наверное. но решение с эксепшнами попроще.

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

Уважаемые, что скажете насчёт этого: http://www.boost.org/community/error_handling.html ?

Шина сообщений, очевидно же

Пока голоса распределились так: двое за шину сообщений и много за эксепшны. Меня шина сообщений пугает.

я бы писал в файл и следил бы за ним из гуя

а как реализуется взаимодействие бэкенда и фронтенда? ядро просто линкуется как скомпилированый obj-файл?

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

> а как реализуется взаимодействие бэкенда и фронтенда? ядро просто линкуется как скомпилированый obj-файл?

просто линкуется как либа, например.

Довольно чоткая концепция, если всё взаимодействие ядра с гуем повесить на неё

А если и ядро, и гуй на Qt, то стоит ли сигналы-слоты использовать?

> Довольно чоткая концепция, если всё взаимодействие ядра с гуем повесить на неё

Да, интересно. Примерно как в mpd. А что почитать на эту тему? Я так понимаю, она плоховата, если между ядром и гуём будет бегать много информации на единицу времени?

Кстати, а что на эту тему почитать можно? Есть какие-нибудь паттерны и примеры?

Как такое лучше делать?

Переписать на лиспе, а в нём реализовать с помощью сигнального протокола.

http://lib.ololo.cc/b/192396/read#t62 (траффик!)

Там в общем-то рассмотрены очереди сообщений для межпроцессного взаимодействия.

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

Я так понимаю, она плоховата, если между ядром и гуём будет бегать много информации на единицу времени?

Смотря сколько много :) У нас по такой схеме (в едином адресном пространстве) стек сигнального протокола разговаривал с UI в кое-каком RT VoIP софте, было вполне сносно.

> Там в общем-то рассмотрены очереди сообщений для межпроцессного взаимодействия

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

Хорошая книжка, хорошая причина купить уже читалку.

И лог нужен и экспешены. Каждое для своего.