Уважаемые разработчики! Планируете ли Вы добавить в MQL5 обработку исключений? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Про затычку согласен, ну а исключения по вашему не затычки? На форуме постоянно звучат слова что mql5 слишком сложен для понимания, так давайте ещё пиханём в него goto исключения и ещё кучу всяких анхронизмов, а ещё лучше перейдём на автокоды (это если помните были такие до ассемблера).
Вас никто не заставляет пользовать функцию как есть, запишите свой варинат исключения (те что нужно делать если идёт деление нулём) и пользуйте.
Что такое исключения - я написал постом выше. Простота языка определяется не тем, насколько мало в нем возможностей, а насколько просто в нем написать простой проект. Для нас потребителей важно, чтобы продукт мог соответствовать запросам совершенно разного уровня. Образно выражаясь, прикладник должен иметь возможность, начав с простой программки, развиваться постепенно в сторону более сложных вещей вроде ООП, исключений и прочего. Платформа должна это предоставлять. Насколько каждая конкретная фича нужна каждому конкретному прикладнику - пусть определит он сам. Если уж ратовать за простоту и ограниченность, то вообще к чему было городить MQL5? Введение ООП по сравнениею с исключениями - на порядки больший шок для неподготовленных программеров.
goto я не просил, не надо передергивать.
По поводу того, чтобы переписать функцию... Было ж сказано, что функция не везде может быть вставлена. Если шагнуть в сторону от деления на ноль, то даже представить сложно, какие навороты из функций потребуется ввести. Как в частности обезопасить обращения к массивам? Писать свой класс массива с проверкой сета и гета? Для каждого типа? И это упрощение для прикладника? Да нифига.
Вы предлагаете каждому прикладнику самостоятельно, подручными средствами реализовывать слабое подобие обработчиков исключений (часть ошибок они не перехвтатят)? А почему это не сделать один раз в самой платформе?
В общем, обсуждать нечего. Уровень разработки в среде МетаТрейдера задают разработчики самого МетаТрейдера.
stringo: ... проверять правильность данных перед их использованием и правильность результатов выполнения функций.
И про то, что для нормальных программистов исключения ненужны...
Странные утверждения...
По вашей логике, например, я в каждой программе в которой использую запись в файл должен сделать кучу проверок на наличие места,
прав доступа и т.д. ? Или запрашивая объект у внешнего сервиса должен все что можно проверить ?
Писать километры кода только потому, что вам лень ? Это бред.
Исключения как раз и появились о того, что мы пишем программы для гетерогенных сред. И запрашивая у системы запись в файл мне в случае невозможности это сделать надо среагировать... и среагировать на причину, а не на факт того, что есть проблема... для этого исключения и нужны...
А то, что вы скоро уже 3-й год не можете отладить свой, пусть и в общем неплохой велосипед, и при этом выдаете какие-то странные отмазки на различные вопросы...
Ну в общем оно не с лучшей стороны вас показывает...
С наилучшими пожеланиями и надеждой хотя бы в конце 2011 года увидеть МТ5 в реале...
Вообще мне вот (а я профессиональный программист) этот дурацкий пример с делением на ноль кажется как минимум странным: это как раз то место, где профессионал использовать исключения НЕ БУДЕТ. Вообще, исключения нужны несколько для другого - более чёткого структурирования программы, по типу "мухи отдельно - котлеты отдельно" и вовсе не для защиты от индусов они были придуманы!
Если рассматривать использование исключений максимально абстрактно, то это такой способ написания программ, когда код пишется в предположении, что ошибок как-бы не бывает вообще. Т.е. представьте себе только: все вызовы всех функций заканчиваются успешно и основной вариант исполнения программы (т.е. собственно то, ради чего программа пишется - ведь профит приносит не обработка ошибок, а выполнение заложенного алгоритма!) не засоряется разными сложными проверками возвращаемых значений.
Приведу несколько более наглядный пример... Допустим, у нас есть некоторая функция, которая читает данные из некоторого абстрактного источника данных, раскодирует её и передаёт вызывающей её функции. Теперь представим работу этой функции в двух вариантах, с обработкой исключений и без:
1.С обработкой исключений, основной код:
а) Создать требуемые ресурсы (например, генератор псевдослучайной последовательности чисел - мало ли как у нас строка закодирована?
б) Выполнить раскодирование строки
в) Освободить ресурсы.
г) Вернуть результат.
Код обработки ошибок: отсутствует. На самом деле он, скорее всего, будет представлен блоками кода try .. finally, в которые будут обёрнуты пункты б (выполняться внутри try .. finally) и в (внутри блока finally: выполниться в ЛЮБОМ случае, если будет возбуждено исключение - оно пойдёт дальше, если нет - выполнится пункт г). Больше никаких специальных телодвижений просто не требуется.
2.Без обработки исключений: Опа - сюрприз: мы должны знать какие ошибки могут возникнуть в источнике данных. :) Предусматриваем, например, возврат кода ошибки и строки комментария, или, в общем, случае, некоторого объекта, который описывает ошибку. Причём объект максимально абстрактный - мы не знаем что там. В результате мы должны предусматривать способ сообщить об ошибках:
а) Фатальных - нехватка памяти, например.
б) Источника данных - вообще не знаем что.
в) Собственных - в строке записан мусор.
г) И т.д.
Подумайте, что будет, когда через некоторое время потребуется сообщать о каких-то новых типах ошибок (обработка которых возможна неизвестно на каком уровне иерархии выше вашего кода) и для них придётся предусмотреть место в интерфейсе вашей функции, а потом поправить код во всех местах, где она используется.
У исключений возможны только два неприятных момента:
1. Реализация ректальным способом. Примеры: C++ (уничтожение статических объектов на стеке - это очень печальная история, которая имеет очень печальные последствия - сложность компилятора, требовательность к ресурсом и т.д. - тема для большой статьи), Java (требование указания возможно генерируемых исключений при определении функций - не намного лучше возврата кода всех на свете ошибок, но её можно обойти, что большинство людей и делают).
2.Индусы. Эти странные люди любят использовать исключения очень странными способами - например, не для обработки ошибок, а для передачи информации между уровнями кода. И да - это может быть проблемой для всех.
Так что лично я - за исключения. Без них всё сложное, что могло бы быть написано на MQL, будет писаться в DLL, как происходило и до сего дня - и никакое ООП этого не изменит. Печально, но факт.
Впрочем, я отлично понимаю, что никто никакие исключения в язык уже не добавит - и так планы горят. Что тоже, в общем, очень печально. :(
Святая наивность...
Люди, не желающие обрабатывать ошибки (думать и знать о них), пытаются отвернуться от них самообманом "исключения лучше, они позволяют не думать об ошибках". Таких не берут в космонавты.
В это теме недавно был удален очень точный комментарий.
Вообще мне вот (а я профессиональный программист) этот дурацкий пример с делением на ноль кажется как минимум странным: это как раз то место, где профессионал использовать исключения НЕ БУДЕТ.
Святая наивность...
Люди, не желающие обрабатывать ошибки (думать и знать о них), пытаются отвернуться от них самообманом "исключения лучше, они позволяют не думать об ошибках". Таких не берут в космонавты.
.....
В это теме недавно был удален очень точный комментарий.
Деление на ноль - самый простой пример исключения. Если уж нам часто не дано заранее знать, какие ошибки могут возникнуть в вызываемом коде, то в их числе может быть и деление на ноль. Не вижу смысла ломать общность подхода. А профессионалы что используют?
Святая наивность...
Люди, не желающие обрабатывать ошибки (думать и знать о них), пытаются отвернуться от них самообманом "исключения лучше, они позволяют не думать об ошибках". Таких не берут в космонавты.
В это теме недавно был удален очень точный комментарий.
угу! написал один индикатор на mql5 - нет проблем, написал мультивалютный индикатор - устал разгребать, добился жесткой синхронизации подкачки истории, но теперь на чарте индикатор или в лог пишет состояние или работает когда историю подкачает, но увы... - в тестере стратегий такое не прокатывает - один раз индикатор может работать , а может и не работать - выдавать ошибку "Array out of range" использую 4 буфера индикатора для расчета данных и один для прорисовки,.
смущает ситуация, что индикатор полурабочий получился - не работал бы - ну и лан, попытался ставить проверки на выход за пределы массива - осознал, что массив для рассчетов(INDICATOR_CALCULATIONS) за меня распределяет mql, решил использовать просто динамические массивы, но благо спохватился, и решил всю работу с массивами тупо вынести в dll на Delphi
интересная ситуация - работать с dll на mql5 стало комфортно, а вот на самом mql полной комфортности чет не видно - зачем урезать возможности базового языка - С++ в mql?????
прекрасно понимаю, что на форуме разработчиков банальный юзер изначально ламер, но обидно если ламеры начнут заполнять кодобазу недостающими ф-циями от МТ4
пока вижу как минимум iMaOnArray() и пр. от МТ4, да и чет нехватает банального сдвига массива на один эл-т вправо/влево, да и тяжело контролировать подгрузку данных в мультивалютных индикаторах
к чему пишу - к тому, что студент 1-го курса технического ВУЗ может написать эти ф=ции на стороннем языке, но увы, разработчики не могут дать полного ф-ционала от терминала, но вместе с тем они могут сделать ограничения, которые по их мнению имеют основания
суть поста - спс за mql5 - но она далека от народной платформы где народ может искать счастья в ДЦ, а если mql5 создавалась как платформа для профессионалов, тогда зачем долбанутые отграничения?
ЗЫ:(интересно, и чегоэт так получилось, что даже на Аль...и МТ5 не видно сразу на главной для скачивания)