Страница 1 из 1
Требуется критика
Добавлено: 29 сен 2006, 10:02
aissp
Кретенький кодец такой...
qq.h
template<class T> void error0(void) {
std::ostringstream ostr;
ostr << T::par1;
throw Exception(T::errcode, ostr.str());
};
template<class T> void error1(const std::string& par) {
std::ostringstream ostr;
ostr << T::par1 << par << T::par2;
throw Exception(T::errcode, ostr.str());
};
struct NotExsistError {
static const ErrCode errcode;
static const char* par1;
static const char* par2;
};
struct ServInternalError {
static const ErrCode errcode;
static const char* par1;
};
.....
qq.cpp
const ErrCode ServInternalError::errcode = vpndbInternalError;
const char* ServInternalError::par1 = "Internal database error.";
..........
myprogram.cpp
if(allBad)
error1<NotExsistError>("Bla Bla Bla");
Ето голая идея, понятно что дальше можо расщирять - заполнять струтуры из файлов, для интернациализации, добавить assert...
Я чего то не могу сообразить где тут оверхед с обычным стилем обработки ошибок, туплю видимо с утра
Добавлено: 29 сен 2006, 12:08
sz
А обычный - это какой?
А критика будет такая:
1. ostr << T::par1 - крайне неэффективная операция. В ассемблер взгляни - ужаснешься. Пиши лучше sprintf. Впрочем, готов согласиться, что в сравнении с швырянием эксепшена это пустяки.
2. Чем городить мутный error1 с какими-то непонятными параметрами, де еще и сомнительных типов, используй лучше функцию с переменным числом параметров и всем известный синтаксис printf.
3. На все типы ошибок классов не напасешься. Почему, собственно, попросту не написать:
template<int code, const char* message> error( ... )
Или даже еще проще:
error( int code, const char* message, ... )
ну а если уж совсем просто, то:
class MyException
{
MyException( int code, const char* message, ... );
};
И, соответственно: throw MyException( ... ). Что собственно такого оригинального делает функция error кроме вызова этого самого throw? На консоль рисует? Ну так это можно и в конструктор запихать. А остальное порезать нафиг бритвой Оккама.
А для интернационализации можно message из параметров убрать и искать по коду в загруженном файле.
Сам просил критику. Просил бы похвалить, я бы похвалил.
Добавлено: 29 сен 2006, 12:29
aissp
Обычный ето ты предложил, ну и подобные
по понктам
1. Да я не зацикливаюсь от те вариант ничего не меняюший...
template<class t, class m> error1(m& qq) {
compile_error;
//or something fancy for m
//m.check();
/m.print();
//what ever
};
template<class t, const char*> error1(m& qq) {
snprintf(" ... %s ...", qq);
};
ну и куча других вариантов
2. Со всеми недостатками принтфа с переменным числом параметров, как то ощибки приведения типов в строке, проблемы с длинной без проверки - короче мне не нравится
3. Вот в етом и состоял вопрос каков оверхед в коде от такого залихватского использования структур - сдается мне никакого но проверять нет желания что-ли, и времени, вдруг кто знает
Добавлено: 29 сен 2006, 12:39
dima
если все это для интернационализации, то подготовь все данные в UTF-8 и пиши код как для чистого английского. Все функции из RTL будут работать.
Добавлено: 29 сен 2006, 12:58
aissp
Internatiolization ето чисто побочный еффект, в том виде с константами как я написал он интерлизеться (тьфу еле выговорил) на етапе компиляции тока. Мне запись такая кажется удобнее, раз, все проверки "типов" проходят на етапе компиляции ето два. Вопрос состоит только в том, что в принципе на каждое сообщение об ощибки я опрделяю тип. Соответственно если у меня 1000 разных сообщений об ощибках - у меня будет объявлено 1000 структур. Допустим мы объявили просто и храбро
char* mess1 = "qq1";
char mess2 = "qq2";
и так 1000 раз, еслть ли питфоллы по сравнению с
struct mess1 {
const char *q;
};
char* mess1::q = "qq1";
Видимо я не очень четко поставил вопрос вверху, такие дела
Добавлено: 29 сен 2006, 13:29
ajkj3em
ну для начала ничего не мешает и error0, и error1 назвать просто error
и в принципе форматировать текстовое сообщение об ошибке в момент
когда она происходит - это не кошерно (если только это не внутренний
дебаг лог).
по сути это привязывает UI к UI-agnostic потрохам, что нарушает
модуляризацию с компартментализацией и всё такое понимаешь ...
Добавлено: 29 сен 2006, 14:01
aissp
Пойнт понятен, тока проблема в том, что необходимо передавать несколько параметров в функцию. Например
А вы (Пользователь, администратор, манаджер) Иванов, ну просто (козел, лох, придурок) потому что у вас нет (прав, мозгов, бабла) чтобы пользоваться етой функцией...
Времена отклика некритичны, система не загружена. Критично написать так чтобы было легко читать и сложно поломать.
Добавлено: 29 сен 2006, 14:12
dima
Нифига не понял, нужно 1000 типов ошибок - сделай класс ошибок с id и текстом ошибки, имей 1000 значени для id.
Добавлено: 29 сен 2006, 14:13
ajkj3em
Код: Выделить всё
enum error_e
{
E_access_denied,
E_not_found,
E_duplicate,
..
};
struct error
{
error_e code;
variant arg1;
variant arg2;
variant arg3;
..
};
throw error(E_access_denied, variant("pupkin"), ... )
ну и надо договориться с самим собой какие args у какого error_e
Добавлено: 29 сен 2006, 14:29
aissp
но тогда где то появляется диспатчер
swithc(error_e code) {
case E_acess_denied:
print(arg1)
case ....:
print(arg1, arg2);
....
}
то есть мы поимели еще и диспетера, что не кошерно имхо.
Лана пойду почитаю про компиляторы, что они там с типами творят

Добавлено: 29 сен 2006, 14:33
aissp
--------------------------------------------------------------------------------
Нифига не понял, нужно 1000 типов ошибок - сделай класс ошибок с id и текстом ошибки, имей 1000 значени для id.
Да нет, еще раз сформулирую вопрос, совсем коротко,а то в философию уползем
какие дополнительные расходы возникают при определнии нового типа, когда надо просто определить строку. Почему ето надо делать, оставим за рамками обсуждения.
Добавлено: 29 сен 2006, 15:16
sz
aissp писал(а):
--------------------------------------------------------------------------------
Нифига не понял, нужно 1000 типов ошибок - сделай класс ошибок с id и текстом ошибки, имей 1000 значени для id.
Да нет, еще раз сформулирую вопрос, совсем коротко,а то в философию уползем
какие дополнительные расходы возникают при определнии нового типа, когда надо просто определить строку. Почему ето надо делать, оставим за рамками обсуждения.
Ответ: никаких.
Но писанины больше.
Добавлено: 29 сен 2006, 15:44
aissp
tanx a lot =)