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

P>Я тебя понял — ты (КЕП!) пытаешься показать, что асинхронный механизм с синхронным плохо совмещается.
я пытаюсь показать что асинхронность с исключениями плохо совмещается

P>Но почему-то приплетаешь сюда исключения. Но это не проблема исключений.
нет, это проблема исключений

P>Ещё раз — исключение передаёт информацию о проблеме выше по стеку вызовов — где стек вызовов в асинхронной модели? Вот то то же и оно.
осталось только понять, почему ты говоришь "то то же и оно" мне, а не себе. Ты же ратуешь за исключения.

P>Во вторых, если как ты говоришь OpenFileAsync — функция асинхронная, она просто не может использовать синхронный механизм, то есть исключения она бросать не может.
Хорошо хоть ты признал что исключения здесь не работают. Жаль только что это заняло у тебя так много времени.

P>Она должна вернуть тебе std::future, который прозрачно бросит исключение при доступе к данным.
И в какой момент я должен доставать оттуда значение?


P>В третьих, если у тебя полностью всё асинхронное, то никаких on_result(FILE) быть не должно, так как обработка ошибок должна вестись в асинхронном режиме тоже. Должно быть on_success и on_fail, в коллбек параметра которого пихается код/объект проблемы.
кому должен? Или перефразируя, чем это лучше возврата значения в коллбек?

P>Но это не код возврата, тут возврата нет, потому и проблем с ними нет. Тут проблемы другого рода.
Дефинируй тогда что такое "возврат". Возможно у тебя какая-то своя, особая терминология.

P>В полностью асинхронной программе архитектура должна быть быть такой, чтобы все проблемы можно было обработать на месте возникновения, что сильно ограничивает область её применения, либо архитектуру (к примеру, полностью событийная архитектура, где ни коды возврата, ни исключения не используются).
А обосновать? В чём проблема с кодами возврата? Коллбеки в которые передаются возвращаемые значения используются повсеместно в асинхронном коде. В чём ограничение?

P>Выбираешь точки обработки ошибок и пишешь в оптимистическом ключе. Гораздо проще чем использовать коды возврата.
Пока выходит что сложнее

A>>Зачем здесь promise/future?
P>Это то, с помощью чего достигается совмещение асинхронного и синхронного кода на плюсах.
Серъёзно? Т.е. до C++11 асинхронного кода в C++ не было? ( кстати, ты слышал что-нибудь про коллбеки? ). Ну и повторю вопрос. В какой момент мне доставать из future?

P>Ну, типичный индусский код
ну я вот всё пытаюсь научится писать с исключениями неиндусский код, но как-то никто даже примера не покажет, как эту простую функцию переписать с исключениями

P>наличие файла проверяется косвенным способом
в коде нет ни слова о проверке наличия файла

P>loadData выполняет не столько load сколько поиск файла
где ты увидел в коде поиск файла?

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

P>Как этот код прошёл у вас ревью непонятно.
Псевдокод на форуме всегда легко проходит код-ревью.

P>А где собственно обработка кодов возврата? Её тут нет.
А суслик?

P>Или ты считаешь, что bool — это и есть код возврата? Тогда понятно, почему не видишь проблем, возникающих с ними.
Там нет bool

P>Возвращение bool подразумевает ветвление, что означает возможность локальной обработки. Фактически bool — это не исключительная, а штатная ситуация.
Там возвращается на bool. Ветвление подразумевает практически любое возвращаемое значение, будь оно bool, int, double, vector<T>, pair<T, err>, что угодно кроме void

P>Вот пример, что такое коды исключений: https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa365430(v=vs.85).aspx , а вот возможные значения https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms681381(v=vs.85).aspx .
P>И их надо обрабатывать для каждой функции.
А 20 лет назад майкрософт учила всех использовать HRESULT. Своя голова на плечах есть?

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

P> Я даже не знаю что тебе на это ответить. Нет. Ты должен обеспечить наличие всего требуемого ещё до вызова loadData, а что не смог обеспечить — то проверить в процессе.
Т.е. ты всеръёз утверждаешь, что прежде чем загрузить данные, я должен сначала а) посмотреть как они заружаются б) проверить условия успешной загрузки ? Вот уже где фейспалм так фейспалм. Инксапсуляция? Не, не слышал.

P>(Иначе получается ситуация: сел поесть, но оказалось что на котлете нет подливы, как собственно и котлеты, да чего уж — и тарелка отсутствует, и сидишь не на кухне, и даже не у себя дома)
Сильная аргументация. Нечего добавить.

A>>Но даже с синхронными вызовами, какого типа исключения должен ловить фремворк, например, который зовёт твои функции? (Подсказка: Откуда он будет знать про твои типы исключений? И про boost::exception? )
P>Фреймворк предоставляет свой набор исключений, который ты можешь использовать либо как есть, либо наследуясь от них.
Ну т.е. boost::exception отпадает. Как отпадают вообще любые типы исключений, не обрабатываемые фремворком. Тогда какие ты исключения будешь бросать? Или ты заранее знаешь все фреймворки, в которых будет использоваться твой код? А если он будет использоваться в двух сразу?


A>>это несомненно. Вопрос больше в том, почему некоторые считают механизм исключений основой обработки ошибок.
P>Потому что, он очень практичен. Ты не понимаешь этого потому, что не пользуешься даже кодами возврата (bool — это не код возврата).
Я не пользуюсь bool. Я пользуюсь возвращаемыми значениями. Почему ты этого не понимаешь и толкуешь про какой-то bool — мне искренне не понятно.

P>Ты описываешь типичный антипаттерн программирования.
где об этом можно почитать?

P>Это всё уже было в истории. А потом изобрели ООП (в частности инкапсуляцию, которая как раз и скрывает от клиента то, что ему не нужно знать) и жизнь стала налаживаться.
Ну, то что ты предполагаешь нарушать инкапсуляцию заради исключений мы уже выяснили, но всё же спрошу, какими боком инкапсуляция соотносится с исключениями?

P>Чисто даже логически то, что это клиент должен решать есть проблема у компонента или нет — это бред, так как только сам компонент владеет наиболее полной информацией о своём выполнении и своих проблемах. А значит ему и решать, когда у него проблемы, а когда нет.
>Клиентский код должен только реагировать на сигналы о проблемах.

Чисто логически OpenFile понятия не имеет, проблема для меня то, что он не мог открыть файл или нет. Как следствие бросать эксепшн — дурость. Надо возвращать результат. А уж клиентский код решит, проблема для него этот результат или нормальная ситуация. Это настолько очевидные вещи что я недоумеваю, почему надо об этом говорить.

P.S.
Ну и да, ты так и не показал как сделать loadFile с исключениями в OpenFile/OpenNetFile

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

P>Я тебя понял — ты (КЕП!) пытаешься показать, что асинхронный механизм с синхронным плохо совмещается.
я пытаюсь показать что асинхронность с исключениями плохо совмещается

P>Но почему-то приплетаешь сюда исключения. Но это не проблема исключений.
нет, это проблема исключений

P>Ещё раз — исключение передаёт информацию о проблеме выше по стеку вызовов — где стек вызовов в асинхронной модели? Вот то то же и оно.
осталось только понять, почему ты говоришь "то то же и оно" мне, а не себе. Ты же ратуешь за исключения.

P>Во вторых, если как ты говоришь OpenFileAsync — функция асинхронная, она просто не может использовать синхронный механизм, то есть исключения она бросать не может.
Хорошо хоть ты признал что исключения здесь не работают. Жаль только что это заняло у тебя так много времени.

P>Она должна вернуть тебе std::future, который прозрачно бросит исключение при доступе к данным.
И в какой момент я должен доставать оттуда значение?


P>В третьих, если у тебя полностью всё асинхронное, то никаких on_result(FILE) быть не должно, так как обработка ошибок должна вестись в асинхронном режиме тоже. Должно быть on_success и on_fail, в коллбек параметра которого пихается код/объект проблемы.
кому должен? Или перефразируя, чем это лучше возврата значения в коллбек?

P>Но это не код возврата, тут возврата нет, потому и проблем с ними нет. Тут проблемы другого рода.
Дефинируй тогда что такое "возврат". Возможно у тебя какая-то своя, особая терминология.

P>В полностью асинхронной программе архитектура должна быть быть такой, чтобы все проблемы можно было обработать на месте возникновения, что сильно ограничивает область её применения, либо архитектуру (к примеру, полностью событийная архитектура, где ни коды возврата, ни исключения не используются).
А обосновать? В чём проблема с кодами возврата? Коллбеки в которые передаются возвращаемые значения используются повсеместно в асинхронном коде. В чём ограничение?

P>Выбираешь точки обработки ошибок и пишешь в оптимистическом ключе. Гораздо проще чем использовать коды возврата.
Пока выходит что сложнее

A>>Зачем здесь promise/future?
P>Это то, с помощью чего достигается совмещение асинхронного и синхронного кода на плюсах.
Серъёзно? Т.е. до C++11 асинхронного кода в C++ не было? ( кстати, ты слышал что-нибудь про коллбеки? ). Ну и повторю вопрос. В какой момент мне доставать из future?

P>Ну, типичный индусский код
ну я вот всё пытаюсь научится писать с исключениями неиндусский код, но как-то никто даже примера не покажет, как эту простую функцию переписать с исключениями

P>наличие файла проверяется косвенным способом
в коде нет ни слова о проверке наличия файла

P>loadData выполняет не столько load сколько поиск файла
где ты увидел в коде поиск файла?

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

P>Как этот код прошёл у вас ревью непонятно.
Псевдокод на форуме всегда легко проходит код-ревью.

P>А где собственно обработка кодов возврата? Её тут нет.
А суслик?

P>Или ты считаешь, что bool — это и есть код возврата? Тогда понятно, почему не видишь проблем, возникающих с ними.
Там нет bool

P>Возвращение bool подразумевает ветвление, что означает возможность локальной обработки. Фактически bool — это не исключительная, а штатная ситуация.
Там возвращается на bool. Ветвление подразумевает практически любое возвращаемое значение, будь оно bool, int, double, vector<T>, pair<T, err>, что угодно кроме void

P>Вот пример, что такое коды исключений: https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa365430(v=vs.85).aspx , а вот возможные значения https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms681381(v=vs.85).aspx .
P>И их надо обрабатывать для каждой функции.
А 20 лет назад майкрософт учила всех использовать HRESULT. Своя голова на плечах есть?

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

P> Я даже не знаю что тебе на это ответить. Нет. Ты должен обеспечить наличие всего требуемого ещё до вызова loadData, а что не смог обеспечить — то проверить в процессе.
Т.е. ты всеръёз утверждаешь, что прежде чем загрузить данные, я должен сначала а) посмотреть в коде как они заружаются б) написать код проверки условий успешной загрузки до вызова loadFile ? Вот уже где фейспалм так фейспалм. Инксапсуляция? Не, не слышал.

P>(Иначе получается ситуация: сел поесть, но оказалось что на котлете нет подливы, как собственно и котлеты, да чего уж — и тарелка отсутствует, и сидишь не на кухне, и даже не у себя дома)
Сильная аргументация. Нечего добавить.

A>>Но даже с синхронными вызовами, какого типа исключения должен ловить фремворк, например, который зовёт твои функции? (Подсказка: Откуда он будет знать про твои типы исключений? И про boost::exception? )
P>Фреймворк предоставляет свой набор исключений, который ты можешь использовать либо как есть, либо наследуясь от них.
Ну т.е. boost::exception отпадает. Как отпадают вообще любые типы исключений, не обрабатываемые фремворком. Тогда какие ты исключения будешь бросать? Или ты заранее знаешь все фреймворки, в которых будет использоваться твой код? А если он будет использоваться в двух сразу?


A>>это несомненно. Вопрос больше в том, почему некоторые считают механизм исключений основой обработки ошибок.
P>Потому что, он очень практичен. Ты не понимаешь этого потому, что не пользуешься даже кодами возврата (bool — это не код возврата).
Я не пользуюсь bool. Я пользуюсь возвращаемыми значениями. Почему ты этого не понимаешь и толкуешь про какой-то bool — мне искренне не понятно.

P>Ты описываешь типичный антипаттерн программирования.
где об этом можно почитать?

P>Это всё уже было в истории. А потом изобрели ООП (в частности инкапсуляцию, которая как раз и скрывает от клиента то, что ему не нужно знать) и жизнь стала налаживаться.
Ну, то что ты предполагаешь нарушать инкапсуляцию заради исключений мы уже выяснили, но всё же спрошу, какими боком инкапсуляция соотносится с исключениями?

P>Чисто даже логически то, что это клиент должен решать есть проблема у компонента или нет — это бред, так как только сам компонент владеет наиболее полной информацией о своём выполнении и своих проблемах. А значит ему и решать, когда у него проблемы, а когда нет.
>Клиентский код должен только реагировать на сигналы о проблемах.

Чисто логически OpenFile понятия не имеет, проблема для меня то, что он не мог открыть файл или нет. Как следствие бросать эксепшн — дурость. Надо возвращать результат. А уж клиентский код решит, проблема для него этот результат или нормальная ситуация. Это настолько очевидные вещи что я недоумеваю, почему надо об этом говорить.

P.S.
Ну и да, ты так и не показал как сделать loadFile с исключениями в OpenFile/OpenNetFile