Уважаемые разработчики! Планируете ли Вы добавить в MQL5 обработку исключений?

 

типа try .. catch

Она ведь не зря присутствует в различных языках. Сильно помогает при написании надежных программ, даже в подконтрольном коде.

Впрочем, Вы и сами об этом знаете :)

Спасибо.

 

Нет, не планируем.

Совсем наоборот, исключения на самом деле не помогают при написании надёжных программ. Огребёте неинициализированных переменных и утечек памяти по полной программе. Я это уже говорил про использование goto.

Всё это - от лени и нежелания проверять правильность данных перед их использованием и правильность результатов выполнения функций.

 
stringo: ... проверять правильность данных перед их использованием и правильность результатов выполнения функций.
Пожалуй, соглашусь, что так лучше
 
falkov:
Пожалуй, соглашусь, что так лучше

Тема обсуждалась вот здесь - https://www.mql5.com/ru/forum/43

То, что пишет товарищ stringo никоим образом не соответствует понятию профессионального программирования. Наличие механизма исключений не отменяет необходимости проверки правильности данных, но дает дополнительный уровень надежности. Про неоспоримое удобство исключений уже было сказано миллион раз. Взять хотя б деление на ноль. Вставлять проверки перед каждым делением - не самый удачный способ улучшения качества программы - она загромождается и становится источником доп. ошибок. И случай с делением тривиальный, а бывают ошибки, которые заранее и не предусмотришь.

По поводу утечек памяти - это уже к вам вопрос как к разработчикам платформы. Можете реализовать без утечек если захотите. Такой проблемы нет.

stringo:

Нет, не планируем.

Всё это - от лени...

Подозреваю, что отказ от исключений происходит как раз из-за лени.

По поводу надежности ПО. Exception handling = must have
По поводу надежности ПО. Exception handling = must have
  • www.mql5.com
Может быть имеет смысл проработать какой-нибудь иной принцип - типа грузить сторонние dll-и не в процесс терминала, а в пулы приложений - отдельные экзешники?
 
marketeer:

Тема обсуждалась вот здесь - https://www.mql5.com/ru/forum/43

То, что пишет товарищ stringo никоим образом не соответствует понятию профессионального программирования. Наличие механизма исключений не отменяет необходимости проверки правильности данных, но дает дополнительный уровень надежности. Про неоспоримое удобство исключений уже было сказано миллион раз. Взять хотя б деление на ноль. Вставлять проверки перед каждым делением - не самый удачный способ улучшения качества программы - она загромождается и становится источником доп. ошибок. И случай с делением тривиальный, а бывают ошибки, которые заранее и не предусмотришь.

По поводу утечек памяти - это уже к вам вопрос как к разработчикам платформы. Можете реализовать без утечек если захотите. Такой проблемы нет.

Подозреваю, что отказ от исключений происходит как раз из-за лени.


Неудачный примерчик, деление на ноль легко устраняется простой функцией которая ничуть не загромождает код.

double ox(double x){if(x==0)return((double )(1.0/pow(10.0,-300)));else return((double )(1.0/x));}

double a=c/b;
double a=c*ox(b);
 

Приведите пожалуйста другой пример иначе лично я сочту что прав Stringo.

 

Очередной холивар.

Когда-то прочитал интересную фразу: "Исключения появились не от хорошей жизни, а от упавшего уровня программистов-разработчиков, которые вместо грамотного построения программы ловят ошибки на выходе."

 

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

Это как пристегивать ремень безопасности. Если я уверен в своем вождении то это не означает что я уверен в трезвости и опытности остальных участников движения особенно тех что несутся по встречной полосе.....

 

Аха. Из-за выросшего объёма индусского кода.

 
Urain:

Неудачный примерчик, деление на ноль легко устраняется простой функцией которая ничуть не загромождает код.

Приведите пожалуйста другой пример иначе лично я сочту что прав Stringo.

если бы была перегрузка операторов как в полноценном С++, Ваш код смотрелся бы идеально, а так - очередной способ восполнить ущербность mql5 по сравнению с уже готовыми решениями в С++

я уже общался с разработчиками, хотелось бы видеть как в С++ :

- перегрузку операторов;

- передачу параметров в конструктор класса (упростились бы методы для распределения и контроля памяти) ;

весьма "криво"  реализованы доступы к таймсессиям, ужасно тяжело синхронизировать мультивалютные индикаторы, написание мультивалютного индикатора занимает 1/3 кода, а перепроверки загрузки исторических данных 2/3 кода 

ЗЫ:  не  пойму зачем разработчики взяли урезали возможности С++ и существующие решения МТ4, от МТ5 чем-то напоминает некую среду разработки софта, совершенно не предназначенного для трейдинга , будем, считать, что я слишком многого хочу от бесплатной платформы 

Построение мультивалютного индикатора с применением множества промежуточных индикаторных буферов
Построение мультивалютного индикатора с применением множества промежуточных индикаторных буферов
  • 2010.05.17
  • Alexey Klenov
  • www.mql5.com
В последнее время возрос интерес к кластерному анализу рынка FOREX. MQL5 открывает новые возможности исследования закономерностей движения валютных пар. Важным преимуществом MQL5, по сравнению с MQL4, является возможность использования неограниченного количества индикаторных буферов. В данной статье описан пример построения мультивалютного индикатора.
 
Urain:

Неудачный примерчик, деление на ноль легко устраняется простой функцией которая ничуть не загромождает код.

Приведите пожалуйста другой пример иначе лично я сочту что прав Stringo.

Вы можете считать все, что угодно ;-). Область программирования имеет некоторые объективные стандарты. Не я их придумал.

Ваша функция - увы всего лишь затычка, выполненная в "лучших" традициях порождения новых проблем вместо их решения. Она загромождает, ИМХО. Эту функцию не удастся использовать в чужом коде, вызываемом как есть (про это тут уже написали), а кроме того совершенно не понятно, с чего это вдруг деление на ноль с помощью функции фактически маскирует ошибку и будет молча выдавать заоблачные результаты, которые скорее всего неправильны для прикладного алгоритма. Потребуется куча других проверок в других местах. Если вам подошла такая обработка деления на ноль, не факт, что подойдет всем.

stringo:

Когда-то прочитал интересную фразу: "Исключения появились не от хорошей жизни, а от упавшего уровня программистов-разработчиков, которые вместо грамотного построения программы ловят ошибки на выходе."

Сомнительная фраза. Не стоит ею руководствоваться. Рассматривайте исключение как штатное средство управления потоком исполнения программы. Еще раз обращаю ваше внимание, что отсутствие исключений не повысит уровень разработчков, а наличие исключений - поможет повысить надежность. Кому исключения не нужны - не будут их использовать. Кому нужны, применят с пользой.

 
marketeer:

Вы можете считать все, что угодно ;-). Область программирования имеет некоторые объективные стандарты. Не я их придумал.

Ваша функция - увы всего лишь затычка, выполненная в "лучших" традициях порождения новых проблем вместо их решения. Она загромождает, ИМХО. Эту функцию не удастся использовать в чужом коде, вызываемом как есть (про это тут уже написали), а кроме того совершенно не понятно, с чего это вдруг деление на ноль с помощью функции фактически маскирует ошибку и будет молча выдавать заоблачные результаты, которые скорее всего неправильны для прикладного алгоритма. Потребуется куча других проверок в других местах. Если вам подошла такая обработка деления на ноль, не факт, что подойдет всем.


Про затычку согласен, ну а исключения по вашему не затычки? На форуме постоянно звучат слова что mql5 слишком сложен для понимания, так давайте ещё пиханём в него goto исключения и ещё кучу всяких анхронизмов, а ещё лучше перейдём на автокоды (это если помните были такие до ассемблера).

Вас никто не заставляет пользовать функцию как есть, запишите свой варинат исключения (те что нужно делать если идёт деление нулём) и пользуйте.


Причина обращения: