Будут ли добавлены в MQL исключительные ситуации? - страница 2

Новый комментарий
 
В любом случае, уверен на 99%, что разработчики не станут реализовывать исключения. Они ориентируются на скорость кода, и не станут её снижать в угоду удобству.
 
Вадим Калашнков #:

Коды возврата кодами возврата, но это другой механизм и используется немного для разных целей. 

По мне - разница невелика. Могу писать хоть с кодами возврата, хоть с исключениями, хоть и с тем и с другим вместе. Если код бросает исключения - то все равно нужен блок их отлова, когда надо высвободить занятые ресурсы или привести систему в "исходное" состояние. В коде нужно отслеживать места, которые могут генерировать исключения... На мой взгляд, особых преимуществ не дают. 

В целом, согласен с мнением Dmitry Fedoseev'a - ""Вопреки верованиям некоторых адептов, не обладает мистической силой". 

 
Georgiy Merts #:

По мне - разница невелика. Могу писать хоть с кодами возврата, хоть с исключениями, хоть и с тем и с другим вместе. Если код бросает исключения - то все равно нужен блок их отлова, когда надо высвободить занятые ресурсы или привести систему в "исходное" состояние. В коде нужно отслеживать места, которые могут генерировать исключения... На мой взгляд, особых преимуществ не дают. 

В целом, согласен с мнением Dmitry Fedoseev'a - ""Вопреки верованиям некоторых адептов, не обладает мистической силой". 

Все удобство в том, catch блок может быть не сразу за местом образования исключения. Для примера:

void MakeSomethingBig(someParams) {
        //100500k суммарных строк кода логики в до ... количестве файлов исходников 
}

void ControlOfSomething(){
        someParams = SOMETHING;
        while (true) {
                try {
                        MakeSomethingBig(someParams);
                }
                catch (someException) {
                        if (condition)
                                someParams = OTHER_PARAMS;
                        else throw;
                }
        }
}

Тут, я в любом месте кода могу кинуть исключение и не заботиться о прерывании алгоритма, кроме как в местах освобождения ресурсов, которые буду освобождать в таком-же catch блоке с дальнейшем пробросом исключения по стеку. Да, это можно сделать через возврат кодов ошибки, более того, исключения сколько-то стоят, но тут как везде, при разработке выбирается баланс. Исключения удобны и позволяют уменьшить количество багов. Так вот, и в с++, и в с#, и в куче других ЯП, выбор мне предоставлен, а тут...

 
Edgar Akhmadeev #:
В любом случае, уверен на 99%, что разработчики не станут реализовывать исключения. Они ориентируются на скорость кода, и не станут её снижать в угоду удобству.

В смысле? Они что, собирают терминал с отключенной поддержкой исключений? Ой, что-то не похоже. Как же подобное без краха терминала у них перехватывается?

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Ошибки, баги, вопросы

Aliaksandr Hryshyn, 2021.08.22 11:18

Код отсюда:

https://www.mql5.com/ru/articles/2432

2021.08.22 12:14:51.105 Tests (EURUSD,M1)       ExpertRemove() function called
2021.08.22 12:14:51.109 Tests (EURUSD,M1)       Access violation at 0x0000022BEE4ED9E4 read to 0x0000000000000000 in 'N:\Alpari MT5\MQL5\Experts\RegExpressions Demo\Tests.ex5'
2021.08.22 12:14:51.109 Tests (EURUSD,M1)          crash -->  0000022BEE4ED9E4 FF10              call       qword near [rax]
2021.08.22 12:14:51.109 Tests (EURUSD,M1)                     0000022BEE4ED9E6 488B17            mov        rdx, [rdi]
2021.08.22 12:14:51.109 Tests (EURUSD,M1)                     0000022BEE4ED9E9 4889F1            mov        rcx, rsi
2021.08.22 12:14:51.109 Tests (EURUSD,M1)                     0000022BEE4ED9EC 41FFD5            call       r13
2021.08.22 12:14:51.109 Tests (EURUSD,M1)                     0000022BEE4ED9EF 48BFD07357EE2B02  mov        rdi, 0x22bee5773d0
2021.08.22 12:14:51.109 Tests (EURUSD,M1)                                      0000
2021.08.22 12:14:51.109 Tests (EURUSD,M1)                     0000022BEE4ED9F9 488B4708          mov        rax, [rdi+0x8]
2021.08.22 12:14:51.109 Tests (EURUSD,M1)                     0000022BEE4ED9FD 4889F9            mov        rcx, rdi
2021.08.22 12:14:51.109 Tests (EURUSD,M1)       
2021.08.22 12:14:51.109 Tests (EURUSD,M1)       00: 0x0000022BEE4ED9E4
2021.08.22 12:14:51.109 Tests (EURUSD,M1)      

Ошибка при закрытии демки. Ошибка при отладке и при релизе.

Последняя бетта-версия терминала.

А если исключения в терминале живут, то почему бы и в mql это доброе не включить?

 
Vladimir Simakov #:

Все удобство в том, catch блок может быть не сразу за местом образования исключения. Для примера:

Тут, я в любом месте кода могу кинуть исключение и не заботиться о прерывании алгоритма, кроме как в местах освобождения ресурсов, которые буду освобождать в таком-же catch блоке с дальнейшем пробросом исключения по стеку. Да, это можно сделать через возврат кодов ошибки, более того, исключения сколько-то стоят, но тут как везде, при разработке выбирается баланс. Исключения удобны и позволяют уменьшить количество багов. Так вот, и в с++, и в с#, и в куче других ЯП, выбор мне предоставлен, а тут...

Все верно. 

Но "в любом месте" - это значит, что приходится либо вставлять блоки CATCH() везде, что захламляет код, и не факт, что не замедляет работу, плюс напротив каждой функции писать в комментариях "//exception", чтобы видеть, какая из них может бросить исключение, а какая нет. 

Для кодов возврата - ты анализируешь их только там, где они реально для тебя важны. 

В целом, для меня разница невелика. Введут разработчики исключения - вероятно, буду их использовать. Не введут - обойдусь. 

 
Georgiy Merts #:

Все верно. 

Но "в любом месте" - это значит, что приходится либо вставлять блоки CATCH() везде, что захламляет код, и не факт, что не замедляет работу, либо напротив каждой функции писать в комментариях "//exception", чтобы видеть, какая из них может бросить исключение, а какая нет. 

Для кодов возврата - ты анализируешь их только там, где они реально для тебя важны. 

В целом, для меня разница невелика. Введут разработчики исключения - вероятно, буду их использовать. Не введут - обойдусь. 

Зачем же везде? Только там, где ресурсы надо явно освобождать. Поменьше new в методах и будет все проще и веселее)))

 
Vladimir Simakov #:

В смысле? Они что, собирают терминал с отключенной поддержкой исключений? Ой, что-то не похоже. Как же подобное без краха терминала у них перехватывается?

А если исключения в терминале живут, то почему бы и в mql это доброе не включить?

В MQL это не включить готовое придется, а реализовать. А обработка исключений снижает скорость кода. И если большинство не станет использовать это, то большинство получит только небольшую потерю производительности, не используя удобства и преимущества.
Лично я двумя руками за обработку исключений (и приравненным к ним ошибкам исполнения, в т.ч. пользовательским). Это очень упрощает написание кода с полным контролем ошибок. Но к технологии надо привыкать. Легко допустить ошибки, например, при переходе исключения между уровнями вложения.
 
Vladimir Simakov #:

Все удобство в том, catch блок может быть не сразу за местом образования исключения. Для примера:

Тут, я в любом месте кода могу кинуть исключение и не заботиться о прерывании алгоритма, кроме как в местах освобождения ресурсов, которые буду освобождать в таком-же catch блоке с дальнейшем пробросом исключения по стеку. Да, это можно сделать через возврат кодов ошибки, более того, исключения сколько-то стоят, но тут как везде, при разработке выбирается баланс. Исключения удобны и позволяют уменьшить количество багов. Так вот, и в с++, и в с#, и в куче других ЯП, выбор мне предоставлен, а тут...

И гарантированно будете ловить утечки ресурсов.

Это беда всех программистов, ловящих эксепшены на уровнях выше. Для языков с garbage collector это не так сильно влияет(влияет), а вот для С++ подобных смертельно.

Поэтому у нас не будет эксепшенов в MQL5.

На эту тему было уже несколько обсуждений и объяснений. Холивар разводить не надо, это принципиальное решение.

 
Vladimir Simakov #:

Зачем же везде? Только там, где ресурсы надо явно освобождать. Поменьше new в методах и будет все проще и веселее)))

Если не везде - тогда надо за каждой функцией, бросающей исключение ставить комментарий "// exception", поскольку без него потом при добавлении кода в блок потребуется выяснять, какая функция кидает, а какая не кидает исключение. 

Про "поменьше new" в местодах - смешно. Ты можешь и не знать, где там, в глубине стека вызовов будет он вызван. 

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

12
Новый комментарий