Возможность выхода по разным веткам из C# кубика

Adigen

Client
Регистрация
28.07.2014
Сообщения
825
Благодарностей
651
Баллы
93
При использовании сниппетов, возможность выхода по красной ветке далеко не всегда удобна, т.к. мешает проекту стопнуться если он словил баг, да и вариантов выхода у сниппета может быть несколько.

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

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

Как-то так:
switchsnippet.png
 

ZennoScript

Moderator
Регистрация
04.03.2011
Сообщения
4 450
Благодарностей
1 880
Баллы
113
1. У кода есть 2 выхода - успешный и не успешный. На не успешном можно возвращать в нужную переменную свои данные и дальше добавить логику - завершать проект с такими данными, или же идти дальше.
2. Если Вы уже работаете с кодом, какой смысл дальше разделять его на 10 выходов? Делайте внутри то, что необходимо и выходите из кубика там, где это действительно логически завершает нужное действие. Т.е. нужно работать дальше - продолжаем делать это в кубике, либо же завершаем по успеху. Нужно прерваться - выходим по не успеху - завершаем шаблон.
3. Если не удобно работать в коде - есть куча готовых инструментов, которые можно использовать и разделять как угодно. Зачем наворачивать не пойми что не пойми куда?
 

nuaru

Main Administrator
Команда форума
Регистрация
14.01.2009
Сообщения
3 641
Благодарностей
2 475
Баллы
113
Да, экшен снипета и экшен логики - это абсолютно разные самостоятельные функциональные единицы, нет никакого смысла в их объединении.
Тем более, что никакой проблемы-то и нет - заводится переменная результата работы снипета, внутри кода ей присваивается нужное значение и она уже отправляется в экшен свича, там по ее значению осуществляется переход по нужной ветке.
 

Adigen

Client
Регистрация
28.07.2014
Сообщения
825
Благодарностей
651
Баллы
93
1. У кода есть 2 выхода - успешный и не успешный. На не успешном можно возвращать в нужную переменную свои данные и дальше добавить логику - завершать проект с такими данными, или же идти дальше.
В том-то и дело что 2, а необходимо 3, успешный, неуспешный и ексепшн, но как это реализовать кроме свича в голову пришел ток вариант с именованым ексепшном, который означает выход по красной ветке а не прекращение работы.
В вашем предложении если я выхожу по неуспешному, то теряю трейс ексепшна + вид шаблона тоже будет веселый + дополнительные проверки, а там упало мое или не мое.

2. Если Вы уже работаете с кодом, какой смысл дальше разделять его на 10 выходов? Делайте внутри то, что необходимо и выходите из кубика там, где это действительно логически завершает нужное действие. Т.е. нужно работать дальше - продолжаем делать это в кубике, либо же завершаем по успеху. Нужно прерваться - выходим по не успеху - завершаем шаблон.
В 99% случаев мне надо разделить и отличить "в коде произшла х.з. какая ошибка" от "это моя ошибка для выхода по красной ветке", оставшийся 1% отлично делается свичем.
Т.е. по факту кубику сниппета надо 3 выхода, зеленая ветка, красная ветка, и ошибка.
И я думаю тут со мной согласится больше 90% пишуших сниппеты.
 

ZennoScript

Moderator
Регистрация
04.03.2011
Сообщения
4 450
Благодарностей
1 880
Баллы
113
Так вызываемые исключение передаются в свою переменную на сколько я помню?
Или я Вас не правильно понял..
Сейчас конечно отладка кода - это та еще задача..
 

Adigen

Client
Регистрация
28.07.2014
Сообщения
825
Благодарностей
651
Баллы
93
Так вызываемые исключение передаются в свою переменную на сколько я помню?
Или я Вас не правильно понял..
Сейчас конечно отладка кода - это та еще задача..
Сейчас project.GetLastError() вообще не дает информации для понимания, что-же случилось в коде, я делал тикет на эту тему (#UQY-327-75971), обещали в следущих весриях сделать.

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

Сейчас я использую 3 костыля, в зависимости от ситуации:
1. Это кубик сниппета, который всегда выходит по зеленой ветке, если он отработал не правильно, он в результате возвращает что-то типа ERROR, и каждый следующий кубик проверяет если на входе еррор, идем к след кубику, это удобно для тех кубиков что в итоге собираются в один цикл, соответствено если в кубике будет непредусмотренный ексепшн, он остановится.
2. Кубик сниппета и за ним свитч который смотрит значение переменной, если ок, идем дальше, если не ок идем по отдельной ветке. ну и если будет ексепшн, то до кубика свича мы не дойдем.
3. Свой тип ексепшна, который я дергаю если мне надо выйти по красной ветке, весь код в кубике обернут в try catch и в конце я проверяю, если ексепшн мой или наследован от него, то делаем п.1, если не мой пишу трейс в лог, перевызываю ексепшн и шаблон отваливается.

Хотелось бы уйти от этих костылей.
 
  • Спасибо
Реакции: artem1024 и deopl

deopl

Client
Регистрация
06.12.2011
Сообщения
656
Благодарностей
126
Баллы
43
Поддержу
 

nuaru

Main Administrator
Команда форума
Регистрация
14.01.2009
Сообщения
3 641
Благодарностей
2 475
Баллы
113
Сейчас я использую 3 костыля, в зависимости от ситуации:
1. Это кубик сниппета, который всегда выходит по зеленой ветке, если он отработал не правильно, он в результате возвращает что-то типа ERROR, и каждый следующий кубик проверяет если на входе еррор, идем к след кубику, это удобно для тех кубиков что в итоге собираются в один цикл, соответствено если в кубике будет непредусмотренный ексепшн, он остановится.
2. Кубик сниппета и за ним свитч который смотрит значение переменной, если ок, идем дальше, если не ок идем по отдельной ветке. ну и если будет ексепшн, то до кубика свича мы не дойдем.
3. Свой тип ексепшна, который я дергаю если мне надо выйти по красной ветке, весь код в кубике обернут в try catch и в конце я проверяю, если ексепшн мой или наследован от него, то делаем п.1, если не мой пишу трейс в лог, перевызываю ексепшн и шаблон отваливается.
Если вам нужно три выхода, то свич, вообще, не нужен. Достаточно одного if
Из снипета красный выход - если происходит критическая не обрабатываемая вами ошибка.
Если вышла по зеленой - то остается два варианта для if - была предвиденная ошибка или нет.
Все.
Никаких костылей тут нет - всего два понятных экшена - свой код и IF
 

Adigen

Client
Регистрация
28.07.2014
Сообщения
825
Благодарностей
651
Баллы
93
Если вам нужно три выхода, то свич, вообще, не нужен. Достаточно одного if
Из снипета красный выход - если происходит критическая не обрабатываемая вами ошибка.
Если вышла по зеленой - то остается два варианта для if - была предвиденная ошибка или нет.
Все.
Никаких костылей тут нет - всего два понятных экшена - свой код и IF
А это не костыль ? мне после 99% кубиков надо ставить ифы получается, чем это отличается от тех костылей что я писал выше ?.
 

Adigen

Client
Регистрация
28.07.2014
Сообщения
825
Благодарностей
651
Баллы
93
Если это надо не часто, вариантов можно придумать массу, но когда это надо постоянно, хотелось-бы чтобы это было реализовано в самом фреймворке.

Вариант со свичем я предложил как ,с моей точки зрения, самый простой в реализации, и удобный для использования.
Хотя насчет удобства вру, кубик с 3мя выходами, будет еще удобнее, а где надо свич, можно его воткнуть после кубика и не париться.
 

nuaru

Main Administrator
Команда форума
Регистрация
14.01.2009
Сообщения
3 641
Благодарностей
2 475
Баллы
113
А это не костыль ? мне после 99% кубиков надо ставить ифы получается, чем это отличается от тех костылей что я писал выше ?.
А зачем вы тогда столько кубиков делаете, пиши все сразу в одном, какой смысл разделять код, если у вас 99% проекта в этом коде...
И это не костыль, т.к. вам нужно объединение двух экшенов, но это нужно только вам и может еще паре человек, а усложнится и без того сложный экшен для всех.
И это только ради того, чтобы у вас был один экшен а не два, что по сути абсолютно одно и то же.

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

Хотя насчет удобства вру, кубик с 3мя выходами, будет еще удобнее, а где надо свич, можно его воткнуть после кубика и не париться.
Первый выход - ошибка, второй - без ошибок, а третий что?
 

Adigen

Client
Регистрация
28.07.2014
Сообщения
825
Благодарностей
651
Баллы
93
А зачем вы тогда столько кубиков делаете, пиши все сразу в одном, какой смысл разделять код, если у вас 99% проекта в этом коде...
И это не костыль, т.к. вам нужно объединение двух экшенов, но это нужно только вам и может еще паре человек, а усложнится и без того сложный экшен для всех.
И это только ради того, чтобы у вас был один экшен а не два, что по сути абсолютно одно и то же.


В глобальном смысле это нужно сверхредко, если рассматривать всех пользователей программы.
У вас просто такой стиль работы, а большинству это не нужно.
В смысле столько кубиков, т.е. вы предлагаете запихнуть весь шаблон в один кубик ?
И как этот кубик на 100500 строк кода отлаживать ? Неимоверное количество func и action даже в студии отладить проблематично, неговоря про ПМ, плюс это банально неудобно, тогда проще писать в CC, но у него есть куча своих минусов, поэтому удобнее использовать PM
Чем удобно писать в кубиках, тем что можно удобно разбить проект на логические блоки, но лепить блоки огромного размера не эффективно.
У меня и так половина кода дергается из длл, таже рекапча например и еще куча всего, если все это запихнуть в кубик. мало того что его хрен отладишь, так он еще и сожрет памяти в многопотоке немеряно.

Устройте опрос, насколько это сверхредко ? Вы удивитесь, как это сверхчасто.

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

Чем усложнится экшн ?, Если мы посмотрим внутреннюю структурую, то кубик сниппета у вас и так обернут в try catch, т.к. красная ветка это выход по Exception, так заведите хотя-бы какой-то ZennoException, от которого я буду наследоваться или дергать его, и в catch проверяем, если Exception не принадлежит к ZennoException, значит у нас реальная ошибка, а если принадлежит, то выход по красной ветке.
Обратную совместимость проектов тут обеспечить не сложно.

Первый выход - ошибка, второй - без ошибок, а третий что?
Первый выход все ок идем дальше, второй выход контролируемая ошибка, т..е та которую я сам вызвал, чтобы уйти по красной веткее, а третий это х,з. какая ошибка, о которой я не в курсе, но которая мне запорет работу всего шаблона, и пока я ее не найду он не заработает нормально, а она может быть плавающая, то есть то нет, и отладка начинает напоминать танцы с бубнами.
3й выход я обработаю в бэденде, или если того требует логика в отдельном кубике, и просто код отключит этот логический блок от выполнения, до того как разберусь.
 
Последнее редактирование:

nuaru

Main Administrator
Команда форума
Регистрация
14.01.2009
Сообщения
3 641
Благодарностей
2 475
Баллы
113
Устройте опрос, насколько это сверхредко, вы удивитесь, что это сверхчасто.
Этот топик и есть опрос - два человека лайкнули, один отписался.
Снипетам несколько лет, а "проблема" появилась только сейчас.
Поэтому я и говорю, что сверхредко.

Для пользователей обычных кубиков это нах не надо. там все просто, а для тех кто пишет сниппеты это актуальный вопрос, чтобы без дополнительного гемора можно было увидеть где ошибки происходят.
Или у вас код всегда идеальный ?, Увольте не поверю, особенно если учесть, что под шаблон даже юниттестов не сделаешь, из-за невозможности экспорта хотя-бы блоков сниппетов.
Мало кто пишет снипеты и много тех, кто их использует копипастом, им всем придется объяснять что это за дополнительный выход такой.

Чем усложнится экшн ?
Увеличением на 50% количеста выходов и если первые два выхода есть у всех экшенов, то третий будет выносить простым пользователям мозг, потому что даже вы толком сами не можете объяснить его назначение и что из него будет выходить и зачем.

Если мы посмотрим внутреннюю структурую, то кубик сниппета у вас и так обернут в try catch, т.к. красная ветка это выход по Exception, так заведите хотя-бы какой-то ZennoException, от которого я буду наследоваться или дергать его, и в catch проверяем, если Exception не принадлежит к ZennoException, значит у нас реальная ошибка, а если принадлежит, то выход по красной ветке.
У нас он обернут чтобы программа совсем не падала.
Если вы хотите обрабатывать эксепшн - обрабатывайте: так же оборачивайте в try catch и обрабатывайте после него, если сработает.
Тогда вы сами можете узнать что за Exception там произошел.
Если пользователь не знаете что это такое try catch, то и расширенный текст этого exception ему возвращать нет смысла, он все равно не знает что с ним делать.

второй выход контролируемая ошибка
И как я буду объяснять простым пользователям снипетов что это за ошибка, которая может быть чем угодно и понятна только создателю этого снипета?
А иногда она, вообще, не будет задействована, потому что даже писатели снипетов в большинстве своем не будут добавлять никаких дополнительных обработок ошибок и этот выход будет не задействован...
И все эти проблемы, только из-за того, что паре-тройке (и то под вопросом) человек лень создать заготовку из двух экшенов для использования кода и обработки возвращаемого результата, а потом копипастить ее во все нужные места?
 

Adigen

Client
Регистрация
28.07.2014
Сообщения
825
Благодарностей
651
Баллы
93
Этот топик и есть опрос - два человека лайкнули, один отписался.
Снипетам несколько лет, а "проблема" появилась только сейчас.
Поэтому я и говорю, что сверхредко.
Давайте не будем путать топик в теме, куда не часто кто заглядывает, с реальным мнением, я вам предложил сделать опрос, чтобы его было видно, и вы поймете насколько эта проблема востребованна.
Я топик отписал, после того как этот вопрос был затронут не с одним человеком, и после того как со своей точки зрения продумал как это может быть в принципе реализовано, свои идеи я высказал, возможно у вас есть другие.

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

Увеличением на 50% количеста выходов и если первые два выхода есть у всех экшенов, то третий будет выносить простым пользователям мозг, потому что даже вы толком сами не можете объяснить его назначение и что из него будет выходить и зачем.
Как это не могу, Объясняю еще раз, 3й выход, это выход по непредусмотренной в сниппете ошибке, даже хрен с ним пусть его не будет, но
мне надо чтобы если случилась ошибка непредусмотренная мной, чтобы я хотябы просто попал в бэд енд, а не продолжил работать дальше.

У нас он обернут чтобы программа совсем не падала.
Если вы хотите обрабатывать эксепшн - обрабатывайте: так же оборачивайте в try catch и обрабатывайте после него, если сработает.
Тогда вы сами можете узнать что за Exception там произошел.
Чтобы программа совсем не падала, такой обертки маловато, для примера смотрим сюда: http://zennolab.com/discussion/threads/serializcija-obekta-cherez-xmlserializer-ronjaet-pm.28424/
Хотя это бага имнно ПМ, но суть думаю понятна.
И в программе он используется у вас для разделения зеленой и красной ветки, если посмотреть код, это неплохо видно )

Если пользователь не знаете что это такое try catch, то и расширенный текст этого exception ему возвращать нет смысла, он все равно не знает что с ним делать.
Мы вроде говорим про пользователей, кто пишет сниппеты. и если у них будет больше гибкости, то поверьте и те кто не знают этого прекрасно поймут, что вот эта ветка это не если не получилось, а если у нас случилась жопа.
И отлично разберутся как воспользоваться этим.


И как я буду объяснять простым пользователям снипетов что это за ошибка, которая может быть чем угодно и понятна только создателю этого снипета?
А иногда она, вообще, не будет задействована, потому что даже писатели снипетов в большинстве своем не будут добавлять никаких дополнительных обработок ошибок и этот выход будет не задействован...
А этот выход в 90% случаев и не будет задействован, его задача будет положить шаблон по ошибке, что в текущей момент, если в сниппете есть выход по красной ветке, нереально.
И если брать ваши доводы, то тем-же пользователям придется объяснять зачем и к сниппету надо еще вот этот кубик, который позволит не загнать их ак в бан, из за незивестного глюка если он вдруг произойдет.

И все эти проблемы, только из-за того, что паре-тройке (и то под вопросом) человек лень создать заготовку из двух экшенов для использования кода и обработки возвращаемого результата, а потом копипастить ее во все нужные места?
Вы издеваетесь ?
Я Вас очень прошу, устройте опрос на эту тему, чтобы было всем видно, давайте посмотрим, пара тройка нас или нет.
 

nuaru

Main Administrator
Команда форума
Регистрация
14.01.2009
Сообщения
3 641
Благодарностей
2 475
Баллы
113
Давайте не будем путать топик в теме, куда не часто кто заглядывает, с реальным мнением, я вам предложил сделать опрос, чтобы его было видно, и вы поймете насколько эта проблема востребованна.
Я топик отписал, после того как этот вопрос был затронут не с одним человеком, и после того как со своей точки зрения продумал как это может быть в принципе реализовано, свои идеи я высказал, возможно у вас есть другие.
Ну давайте сейчас рассылку устроим с голосованием, привлечем всех клиентов и будем решать этот сверхважный вопрос.
Этот раздел предложений создан для того, чтобы каждый мог предложить свою идею. И действительно востребованные идеи, не противоречащие концепции программы, мы реализуем.

Не придется если сделать обратную совместимость, вы же не объясняете всем, что это за галочка появилась , не возвращать значение, в списке изменений написали, и достаточно.
Дело не в совместимости, а в совершенно лишней настройке, которая:
1) непонятна и не очевидна даже среднему пользователю программы.
2) нужна только самым активным писателям снипетов и то не всем (как минимум один такой человек написал, что эта фича лишняя)

Как это не могу, Объясняю еще раз, 3й выход, это выход по непредусмотренной в сниппете ошибке, даже хрен с ним пусть его не будет, но
мне надо чтобы если случилась ошибка непредусмотренная мной, чтобы я хотябы просто попал в бэд енд, а не продолжил работать дальше.
Я предложил свою нумерацию, где аварийная неконтролируемая ошибка - второй выход, вам она не понравилась и вы назвали этот выход третьим.
Нумерация не важна. Кроме обычных двух выходов, которые абсолютно очевидны, вы добавляете третий, по которому выход происходит только если сделать дополнительные обработки, а кроме выхода, ему еще нужно как-то передовать дополнительный параметр, который бы сообщал что, собственно случилось, а иначе этот выход бесполезен.
В итоге, этот выход опять будет вести на свич, чтобы разбирать код ошибки.
Т.е. дополнительные усложненные костыли на велосипедных колесах.
Это абсолютно очевидно, но вы все равно настаиваете на них, как будто сложно создать заготовку и копипастить ее везде, где нужно.

Чтобы программа совсем не падала, такой обертки маловато, для примера смотрим сюда: http://zennolab.com/discussion/threads/serializcija-obekta-cherez-xmlserializer-ronjaet-pm.28424/
Хотя это бага имнно ПМ, но суть думаю понятна.
И в программе он используется у вас для разделения зеленой и красной ветки, если посмотреть код, это неплохо видно )
Ну давайте ее уберем и программа будет падать не в одном конкретном слчуае работы с XML (что является багой), а всегда когда должен быть выход по красной ветке.
Неужели не очевидна разница между 0,01% и 99,9%?
Какой смысл было это писать? Чтобы просто поспорить?
Давайте, вообще, трай кечи уберем из всего постера, пусть он сразу падает всегда.

Мы вроде говорим про пользователей, кто пишет сниппеты. и если у них будет больше гибкости, то поверьте и те кто не знают этого прекрасно поймут, что вот эта ветка это не если не получилось, а если у нас случилась жопа.
И отлично разберутся как воспользоваться этим.
Я говорю про всех пользователей, а вы говорите про себя лично.
И меня не интересует ветка, по которой происходит выход если случилась жопа, с ней все прозрачно, мы сейчас говорим о новой, дополнительной ветке, которой не было раньше и по которой мы выходим когда происходит обрабатываемая ошибка. Ошибка, которую нужно сначала поймать, а потом еще и передать дальше по ходу выполнения в свич (от чего и хотели избавиться изначально).

А этот выход в 90% случаев и не будет задействован, его задача будет положить шаблон по ошибке, что в текущей момент, если в сниппете есть выход по красной ветке, нереально.
Он не будет задействован в 99,99% случаев при использовании этого снипета, поэтому я и говорю, что он не нужен чуть более чем никому.
А усложнять программу он будет всем, кто использует снипеты.
И нет тут ничего не реального, все решается в три шага:
1) оборот всего снипета в трай кеч
2) заведением локальной переменной в проекте куда будет записываться код ошибки (если сработал трай) или факт ее отсутствия, если все прошло хорошо
3) создания экшена свич, который будет перенаправлять выполнение шаблона в зависимости от работы снипета.


И если брать ваши доводы, то тем-же пользователям придется объяснять зачем и к сниппету надо еще вот этот кубик, который позволит не загнать их ак в бан, из за незивестного глюка если он вдруг произойдет.
За годы использования этого снипета еще никто не задал этот вопрос.
А тем кто задаст, я расскажу как что есть свич и как прекрасно он решает проблему контролируемой ошибки.


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

Adigen

Client
Регистрация
28.07.2014
Сообщения
825
Благодарностей
651
Баллы
93
Мы ушли не туда, давайте я еще раз объясню суть проблемы.
Моя ошибка в том, что я попытался сразу предложить решение, забудем про свичи, третьи выходы и т.п.

Итак проблема номер раз:
Если я не использую красную ветку у кубика, то при возникновении ошибки, в BadEnd я абсолютно ничего не могу узнать о том что за ошибка меня туда привела, кроме ид кубика, что для сниппета не говорит ничего.

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

Первую проблему решили, через GetLastError() можно будет получить ссылку на ексепшн который сработал, и тогда в BadEnd можно будет определять как мы упали.
А вот как элегантнее решить вторую, я без понятия.
 

surrealmix

Client
Регистрация
07.03.2013
Сообщения
715
Благодарностей
410
Баллы
63
C#:
namespace ZennoLab
{

    public public static class ProjectExtensions
    {
        //В кубике ловим исключение и вызываем project.StoreException(ex);
        public static void StoreException(this IZennoPosterProjectModel project, Exception ex)
        {
            project.Context["Exception"] = ex;
        }
       
        //В следующем кубике проверяем было ли исключение
        //project.HasException
        public static void HasException(this IZennoPosterProjectModel project)
        {
            if(project.Context["Exception"] != null)
            {
                var ex = (Exception)project.Context["Exception"];
                // дальше можем писать влог, файл или ...
            }
        }
    }
}
Таким образом с помощью 2-х строк в сниппете мы избавляемся от ненужного кубика.
 

surrealmix

Client
Регистрация
07.03.2013
Сообщения
715
Благодарностей
410
Баллы
63
Чем разработчикам тратить время на 3 выхода из кубика, лучше потратить его на улучшение теперешнего редактора кода (свой код C#), думаю что это предложение должно набрать большое количество голосов.
 

amyboose

Client
Регистрация
21.04.2016
Сообщения
2 312
Благодарностей
1 191
Баллы
113
Пиши сразу правильный код, так как гавнокодить тут любой может, а вот делать по-настоящему быстрый и правильный код далеко не просто
 

Adigen

Client
Регистрация
28.07.2014
Сообщения
825
Благодарностей
651
Баллы
93
Таким образом с помощью 2-х строк в сниппете мы избавляемся от ненужного кубика.
У меня подобным образом и сделано,
C#:
return CodeValidator(()=>{ 
  // тут код, который при падении будет проверен на то где упал, почему упал, упал правильно или нет и т.п.
});
Чем разработчикам тратить время на 3 выхода из кубика, лучше потратить его на улучшение теперешнего редактора кода (свой код C#), думаю что это предложение должно набрать большое количество голосов.
Отладку в студии делать надо, лучше чем студия редактор не сделают однозначно, а в пм уже тестировать готовые блоки.
 

nuaru

Main Administrator
Команда форума
Регистрация
14.01.2009
Сообщения
3 641
Благодарностей
2 475
Баллы
113
Чем разработчикам тратить время на 3 выхода из кубика, лучше потратить его на улучшение теперешнего редактора кода (свой код C#), думаю что это предложение должно набрать большое количество голосов.
Вопрос даже не во времени, его мы как раз найдем.
Вопрос в том, что маленькое неудобство для одного человека предлагается решить засчет создания неудобства для большинства других пользователей.

В новой версии будет возможность вернуть подробное описание ошибки через
project.GetLastError().Exception
а уж обработка этих ошибок останется на плечах писателя снипета.
 

Кто просматривает тему: (Всего: 1, Пользователи: 0, Гости: 1)