Здравствуйте, уважаемые коллеги.

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

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

Также приветствуются оригинальные идеи.

P.S. Исключения в нашем проекте невозможно использовать, так как, к сожалению, обстановка с платформами, особенно мобильными, такова, что если вы рассчитываете написать портируемый код, про некоторые возможности C++, в частности, исключения, придется забыть, так как разработчики платформ по каким-то причинам любят плевать на их реализацию. Текущий конкретный пример такой платформы — Samsung Bada, а также, до недавнего времени, Android (вроде бы там уже сделали исключения, я за этим не следил). В нашем проекте на текущий момент нет какого-то определенного способа обработки ошибок, и, в целом, обработка ошибок недостаточна, а во многих местах вообще не делается. Хотелось бы исправить ситуацию, поэтому и задаю вопрос.

Здравствуйте, <Аноним>, Вы писали:

А>Android (вроде бы там уже сделали исключения, я за этим не следил).

На Андроиде можно было использовать исключения с самого появления NDK — только надо было это NDK "пофиксить".

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, уважаемые коллеги.

А>Понимаю, что во многом моя тема дублирует много раз обсуждавшиеся здесь вопросы

да, дублирует — http://rsdn.ru/forum/cpp/4360425.aspx

Автор: Abyx
Дата: 28.07.11

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

ИМО, проблема только в конструкторах.

из функции\метода ошибка возвращается обычным способом
— результат (в т.ч. boost.optional)
— параметр: foo(..., err_t& err)
— специальный метод err_t lastError(); bool good();
— глобальная TLS переменная (локальная для потока) например GetLastError в винде

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

А>>Понимаю, что во многом моя тема дублирует много раз обсуждавшиеся здесь вопросы

A>да, дублирует — http://rsdn.ru/forum/cpp/4360425.aspx

Автор: Abyx
Дата: 28.07.11

Я видел эту тему, там больше обсуждают конкретное решение, предложенное автором.

Здравствуйте, Abyx, Вы писали:
A>ИМО, проблема только в конструкторах.

По большому счету, да. Но это, IMHO, одна из основных проблем. Но при использовании объектов любая операция над объектом должна следующим шагом предполагать проверку состояния объекта, и код, не написанный специально под такую модель, не годится к использованию в проекте с отсутствием исключений — т.е. не годится почти любой код. STL как минимум. Уберите STL, уберите шаблоны, уберите перегрузку операторов, и пишите на старом добром C. В этом на самом деле нет особых проблем на мой взгляд, мне как-то пришлось делать проект на простом C, так я его делал так, как делал бы на C++, только работы немного больше, раза в 2-3-5.

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

M>Уберите STL, уберите шаблоны, уберите перегрузку операторов, и пишите на старом добром C.
как все это связано с исключениями?
где исключения в std::transform ? как они связаны с шаблонами? а с перегрузкой операторов?

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

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

M>>Уберите STL, уберите шаблоны, уберите перегрузку операторов, и пишите на старом добром C.
A>как все это связано с исключениями?
Как это все связано с иключениями, или не связано — это тема отдельного исследования, которое тоже увеличивает количество работы, которую надо произвести.

A>где исключения в std::transform (1)? как они связаны с шаблонами (2)? с перегрузкой операторов (3)?

1) std::transform

template < class InputIterator, class OutputIterator, class UnaryOperator >
  OutputIterator transform ( InputIterator first1, InputIterator last1,
                             OutputIterator result, UnaryOperator op );

template < class InputIterator1, class InputIterator2,
           class OutputIterator, class BinaryOperator >
  OutputIterator transform ( InputIterator1 first1, InputIterator1 last1,
                             InputIterator2 first2, OutputIterator result,
                             BinaryOperator binary_op );

Может ли OutputIterator или UnaryOperator/BinaryOperator сообщить об ошибке? Как? Покажите пальцем на тех, кто проверяет консистентность результата после std::transform.

2) См п.3. Как вы можете гарантировать, что использование шаблонов не вызовет п.3 или еще какой-то сайд эффект? Если вы пишете проект один, в этом есть уверенность, примерно 60-процентная, вдвоем — уже где-то 20, втроем — тут уже без четвертого (злого манагера) точно не обойтись.
3) А как перегруженный оператор+ может сообщить об ошибке, если его семантика вполне определена, как возврат некой суммы аргументов 1 и 2?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, уважаемые коллеги.

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

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

А>Также приветствуются оригинальные идеи.

А>P.S. Исключения в нашем проекте невозможно использовать, так как, к сожалению, обстановка с платформами, особенно мобильными, такова, что если вы рассчитываете написать портируемый код, про некоторые возможности C++, в частности, исключения, придется забыть, так как разработчики платформ по каким-то причинам любят плевать на их реализацию. Текущий конкретный пример такой платформы — Samsung Bada, а также, до недавнего времени, Android (вроде бы там уже сделали исключения, я за этим не следил). В нашем проекте на текущий момент нет какого-то определенного способа обработки ошибок, и, в целом, обработка ошибок недостаточна, а во многих местах вообще не делается. Хотелось бы исправить ситуацию, поэтому и задаю вопрос.

Исключения, среди прочего, были созданы для того чтобы убрать из языка GOTO. Используйте безусловный переход для программирования конечных автоматов. Эмуляцию событийного механизма для Си могу подбросить.

PS. Я вспомнил, что как-то писал эмуляцию исключений под Си с использованием деректив препроцессора, но никак не найду в своих архивах пример . Идея в том, чтобы заменять незнакомые для языка слова try, throw и catch чем-то знакомым.
С тех пор, как мозг попробовал на вкус ООП, его трудно накормить чем-то другим .

Здравствуйте, Abyx, Вы писали:
A>ИМО, проблема только в конструкторах.

А если ещё учесть, что конструкторы могут вызываться неявно, невидимо для пользователя…

Да и удобнее написать f(C(x, g(y)[i])), чем

t1 = g(y, err);
if(!err) { ...; return; }
t2 = t1.get(i);
if(!t2) { ...; return; }
t3 = C(x, t2);
if(!t3.isValid()) { ...; return; }
t4 = f(t3);
if(lastError()) { ...; return; }
res = t4;

A>из функции\метода ошибка возвращается обычным способом
A>- результат (в т.ч. boost.optional)
A>- параметр: foo(..., err_t& err)
A>- специальный метод err_t lastError(); bool good();
A>- глобальная TLS переменная (локальная для потока) например GetLastError в винде

Хотя, конечно, и из конструктора можно ошибку возвращать «обычным способом»:

• заменив его фабрикой,
  
• параметр,
  
• специальный метод,
  
• глобальная TLS переменная (локальная для потока).

Только это сильно ограничивает парадигму программирования, превращая C++ в какой-нибудь… макроассемблер.

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

A>>где исключения в std::transform (1)? как они связаны с шаблонами (2)? с перегрузкой операторов (3)?

M>1) std::transform

M>Может ли OutputIterator или UnaryOperator/BinaryOperator сообщить об ошибке? Как? Покажите пальцем на тех, кто проверяет консистентность результата после std::transform.

редко когда итератор станет бросать исключения. это знаете ли сложно, если итератор это указатель или обертка над указателем.

если консистентность результата вызывает сомнения — то ее надо проверить, после чего бы то ни было %)

M>2) См п.3. Как вы можете гарантировать, что использование шаблонов не вызовет п.3 или еще какой-то сайд эффект? Если вы пишете проект один, в этом есть уверенность, примерно 60-процентная, вдвоем — уже где-то 20, втроем — тут уже без четвертого (злого манагера) точно не обойтись.
какие сайд-эффекты?
шаблоны — это метапрограммирование и работают во время компиляции.
после того как они инстанцированы — это обычный код "без шаблонов", и все его пролемы — это проблемы кода без шаблонов %)

вы вообще о каких шаблонах? о тех которые в boost.mpl? или о тех которые в boost.gil?
std::pair может бросать исключения? или auto_ptr?

M>3) А как перегруженный оператор+ может сообщить об ошибке, если его семантика вполне определена, как возврат некой суммы аргументов 1 и 2?
NaN, обрезанная строка, да как угодно
как strcat сообщает об ошибке?

перегрузка операторов — это не перегрузка арифметических операторов.
в умных указателях тоже перегрузка операторов, и в библиоткех ввода\вывода перегрузка операторов,
и в boost'овских spirit, phoenix, lambda, expressive — тоже перегрузка операторов

-------

С++ состоит не из одних исключений.
Странно думать, что если убрать из языка исключения — на нем нельзя будет писать %)

On 29.07.2011 21:19, Аноним 14 wrote:

> Samsung Bada, а также, до недавнего времени, Android (вроде бы там уже сделали

Андроид же операционка, исключения в языке программирования.
Как вообще операционка с исключениями связана, объясни, а ?

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


A>>где исключения в std::transform (1)? как они связаны с шаблонами (2)? с перегрузкой операторов (3)?
M>1) std::transform

[...]

M>Может ли OutputIterator или UnaryOperator/BinaryOperator сообщить об ошибке? Как? Покажите пальцем на тех, кто проверяет консистентность результата после std::transform.

Да не каждый функтор сообщает об ошибке, а итераторы вообще исчезающе редко когда стреляют исключениями.
Так что множество стандартных алгоритмов никуда не деваются: *sort, *_heap, remove*, *_bound, min*/max*, *_permutation, count* и множество других будут работать как ожидается.

Здравствуйте, Аноним, Вы писали:

А>P.S. Исключения в нашем проекте невозможно использовать, так как, к сожалению, обстановка с платформами, особенно мобильными, такова, что если вы рассчитываете написать портируемый код, про некоторые возможности C++, в частности, исключения, придется забыть, так как разработчики платформ по каким-то причинам любят плевать на их реализацию.

Если хочется секса, то можно его поиметь с setjmp/longjmp

You will always get what you always got
  If you always do  what you always did

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

J>Если хочется секса, то можно его поиметь с setjmp/longjmp
Я бы в этом случае взял реализацию из posgresql.

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

J>Здравствуйте, Аноним, Вы писали:

А>>P.S. Исключения в нашем проекте невозможно использовать, так как, к сожалению, обстановка с платформами, особенно мобильными, такова, что если вы рассчитываете написать портируемый код, про некоторые возможности C++, в частности, исключения, придется забыть, так как разработчики платформ по каким-то причинам любят плевать на их реализацию.

J>Если хочется секса, то можно его поиметь с setjmp/longjmp
Суровый ты мужик.

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

J>Если хочется секса, то можно его поиметь с setjmp/longjmp

Да, это старое известное извращение. Самое смешное, что на тех же кривых платформах (e.g. Bada), где нет исключений, нет и setjmp. Правда, я бы все равно не стал так делать.

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

J>Здравствуйте, Аноним, Вы писали:

А>>P.S. Исключения в нашем проекте невозможно использовать, так как, к сожалению, обстановка с платформами, особенно мобильными, такова, что если вы рассчитываете написать портируемый код, про некоторые возможности C++, в частности, исключения, придется забыть, так как разработчики платформ по каким-то причинам любят плевать на их реализацию.

J>Если хочется секса, то можно его поиметь с setjmp/longjmp

Можно обернуть setjmp/longjmp в макросы типа TRY(), THROW(), CATCH() и т.д. как это сделал David R. Hanson в "C Interfaces and Implementations: Techniques for Creating Reusable Software". Это конечно не С++ исключения с их вызовом деструктора и разными другими фитчами, но в мире Си смотрится очень продвинуто! Посмотрите, думаю Вам понравится..