Нужно ли удалять ветки неявно критикующие язык MQL - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну, исходя из того, что "МТ5 - биржевой терминал", где встречных позиций нет - это, на мой взгляд, было вполне оправдано.
Другое дело, что большинство усовершенствований МТ5 понадобились и для форекс-контор, где народ давно привык к локированию. (Типа "убытка еще нет"). Разработчикам пришлось согласиться.
Так вот этот подход "МТ5 - биржевой терминал" и был в корне неверен. Ну сколько у нас торгует на бирже и сколько на форе? Думаю, распределение 5% / 95%
Ну, исходя из того, что "МТ5 - биржевой терминал", где встречных позиций нет - это, на мой взгляд, было вполне оправдано.
Другое дело, что большинство усовершенствований МТ5 понадобились и для форекс-контор, где народ давно привык к локированию. (Типа "убытка еще нет"). Разработчикам пришлось согласиться.
Я эту тему поднимал год-полтора назад. Ренат очень жестко сказал, что этого никогда не будет, потому что это замедляет, усложняет и еще 100500 *-яет программу. И что исключения не нужны в программировании.
Не только Ренат так думает (например, так же считает Google) и не только касаемо MQL.
Самый серьезный аргумент - когда вы пишете на языке, где есть эксепшны и используете код, который может кинуть эксепшн - вы должны быть готовы к тому, что в любой строке может быть брошено исключение - и ход программы прервётся там, где вы этого не ожидаете.
Надо ли уточнять, к чему это может привести?
Или вы любую сомнительную строку будете обвешивать try/catch блоками? Но это заведомо хуже, чем проверка кода возврата.
Недаром даже в C++11 появился-таки оператор noexcept.
Не только Ренат так думает (например, так же считает Google) и не только касаемо MQL.
если вы про go то там есть исключения, просто скажем так неканоничные.
Надо ли уточнять, к чему это может привести?
видите ли... в mql в любом случае уже есть исключения, например деление на ноль, обращение к невалидному указателю. они фатальны и неконтролируемы.
Или вы любую сомнительную строку будете обвешивать try/catch блоками? Но это заведомо хуже, чем проверка кода возврата.
нет, практика показывает, что выстрелить себе в ногу одинаково легко и в том и в том случае.
Недаром даже в C++11 появился-таки оператор noexcept.
которым практически никто не пользуется, как и спецификацией исключений в целом, потому что соблюдать ее это страшный гемор и еще один способ выстрелить себе в ногу
_____________
сразу оговорюсь что я не против отсутствия исключений в MQL, считаю что нормально можно писать и с ними, и без
Не только Ренат так думает (например, так же считает Google) и не только касаемо MQL.
Самый серьезный аргумент - когда вы пишете на языке, где есть эксепшны и используете код, который может кинуть эксепшн - вы должны быть готовы к тому, что в любой строке может быть брошено исключение - и ход программы прервётся там, где вы этого не ожидаете.
Кстати, да.
В той конторе, где я работал, писали на С++, был обязателен комментарий "// exception" на любой строке, которая могла бросить исключение.
Но, я не вижу никаких проблем, чтобы "обвесить try-catch" операторами блок. По сути, эти операторы нужны там, где в блоке запрашиваются какие-то ресурсы - в случае исключения от них необходимо отказаться. Но и в случае кодов возврата происходит тоже самое - в случае ошибки надо отказаться от запрошенных ресурсов.
В общем, для меня - что исключения, что коды возврата - разница невелика.
если вы про go то там есть исключения, просто скажем так неканоничные.
с Go я почти незнаком, слышал, что там может быть заменен тип возвращаемого значения в случае ошибки, но (если это так) - это же не exception с раскруткой стека и прочим.
Я писал про стандарт кодирования Google на C++ ( https://google.github.io/styleguide/cppguide.html#Exceptions )
видите ли... в mql в любом случае уже есть исключения, например деление на ноль, обращение к невалидному указателю. они фатальны и неконтролируемы.
Неконтролируемы? Это покрывается проверками в коде. Хорошо написанный код не будет делить на ноль или обращаться к невалидному указателю
нет, практика показывает, что выстрелить себе в ногу одинаково легко и в том и в том случае.
Если не делать проверки - то рано или поздно выстрел в конечности неизбежен, согласитесь.
которым практически никто не пользуется, как и спецификацией исключений в целом, потому что соблюдать ее это страшный гемор и еще один способ выстрелить себе в ногу
Как это не пользуются? В сотне мест в STL (которым пользуется 80% разрабов) функции уже объявлены как noexcept.
Зачем это сделано, хорошо объяснено, например, у Мейерса ( https://coollib.com/b.usr/Skott_Meyers_Effektivnyiy_i_sovremennyiy_C%2B%2B.pdf ), раздел. 3.8
Но, я не вижу никаких проблем, чтобы "обвесить try-catch" операторами блок. По сути, эти операторы нужны там, где в блоке запрашиваются какие-то ресурсы - в случае исключения от них необходимо отказаться. Но и в случае кодов возврата происходит тоже самое - в случае ошибки надо отказаться от запрошенных ресурсов.
Но зачем try/catch вместо проверок? Чтобы поймать exception из недр стека?
Т.е., например, если стек представляет собой нечто вроде unhuman() -> evil() -> dounsafe() и что-то пошло не так в недрах dounsafe()? ОК.
Что полезного мы узнаем из того факта, что нечто в потрохах функций сломалось, а разработчик(и) этих функций не побеспокоились об уместной, своевременной обработке нештатных ситуаций? Выведем в лог ошибку "Something went wrong" (если в exception вообще будет хоть какой-то payload) и все равно завершимся? :)
Не напоминает ли это использование goto - пусть и более "аккуратное" (=> более затратное по ресурсам)?
Ну в общем что говорить - на мой взгляд, гугл (ссылка выше) все грамотно изложил.
Но зачем try/catch вместо проверок? Чтобы поймать exception из недр стека?
Где-то хороши try..catch, а где-то коды возврата. Надо и то, и другое. И друг друга далеко не везде заменяют. Дискуссия ни о чем.
}
catch(...)
{
// конец дискуссии :)
std::terminate();
}