Попробовать.. Блоки выгоды, всегда дорогие? [дубликат]

Это более подробное описание того, как использовать Winmerge в TFS- http://www.neovolve.com/post/2007/06/19/using-winmerge-with-tfs.aspx

Эти макросы являются задержкой с тех дней, когда приложение, возможно, действительно хотело компилировать юникод и версию ANSI.

Сегодня нет никаких оснований для этого - все это является остаточным. Microsoft всегда поддерживает все возможные конфигурации, но это не так. Если вы не занимаетесь компиляцией как в ANSI, так и в Юникоде (а никто нет, давайте будем честны), просто перейдите к с L «text».

И да, на случай, если до сих пор не было ясно: _T = = _TEXT

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

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

Просто для поиска адвоката Devils - я нашел отличное использование для использования исключения для управления потоком: кнопка «Отмена».

Если у вас есть функция, работающая на каком-либо сервисе, которая может занять 10-120 минут, что делает кучу разных вещей, я обнаружил, что делает (если (галантереил) бросить новое JobcancelledException () внутри моего журнала () Функция (которая логит на каждом шаге, на котором я нахожусь), чтобы работать просто Friggan Awesome. Он выручает из текущего выполнения кода и останавливает работу - именно то, что мне нужно. Я уверен, что есть какой-то лучший способ сделать это, может быть, как-то использует события - но для моего случая работает отлично (особенно поскольку рабочие места не регулярно отменены).

Другое, что, хотя - я на 100% в соответствии с соглашением, что исключения никогда не следует использовать в качестве инструмента управления потоком ..

@Kornel - у меня два слова для этого поста ... Святой $ Hit =)

Вот простой образец псевдо-кода:

Class Job
{
       Public Run(param1,param2,etc...)
       {
             Try
            {
                   Log("Doing Something")
                   DoSomething()

                         Log("Doing Another")
                         DoAnother()

                         Log("This keeps going, etc, inside of these function we make the same Log calls where it makes sense")
                         Etc()
                   }
                   Catch(JobCancelledException)
                   {
                        status="Cancelled"
                   }
            }

              Private Log(ByVal str As String)
              {
                      MessateToUser(str)

                      if(hasCancelled)
                          throw new JobCancelledException
            }

             private SomeEvent_WhenUserPushesCancelButton()
             {
                       hasCancelled=True
             }
}

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

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

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

Это зависит от языка, но, насколько я знаю в Java, если исключение не будет брошено, есть рядом с производительностью, чтобы получить . Попробую / Cav .

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

Исключения являются только дорогими, если исключение брошен. Я уверен, что есть несколько минимальных затрат, чтобы настроить блок Try..Catch, но это, безусловно, перевешено стоимостью, которые вообще не поймают исключение и имея падение вашей программы. Поскольку другие указали, попробуйте ...catch Blocks следует использовать только для исключительных обстоятельств.

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

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

string invalidAddress = "notvalid@@@@@@lolzors.bomb";
return MailAddressValidator.IsValid(invalidAddress ); // doesn't cause exception

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

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

из wikipedia: dynamic language runtime

Службы DLR в настоящее время используются в версия для разработки IronRuby, .NET реализация Ruby и для IronPython.

В 2007 году Microsoft планировала использовать DLR для предстоящей версии Visual Basic .NET 10.0 (VBx) и Managed JScript (ECMAScript 3.0). Однако по состоянию на август 2009 года Microsoft больше не имеет планов для реализации Managed JScript (ECMAScript 3.0) на DLR, и больше никаких упоминаний о Visual Basic .NET работает с DLR был создан Microsoft на Visual Базовые обновления для разработки. Аналогично C #, Visual Basic сможет доступ к объектам из динамических языков построен на DLR, такой как IronPython и IronRuby [.

IronScheme, предстоящая схема реализация [, планировала на основе DLR, но решил отказаться от этой идеи, потому что DLR ветвь используемого проекта вышла из синхронизировать с багажником, а также потому, что DLR, по словам разработчиков, не может поддержать большинство Требования схемы.

Пробовали ли вы использовать

data.AssertWasCalled(x => x.ListCount(1) = Arg.Is(EXPECTED_VALUE));

try.. блоки catch никогда не должны использоваться в качестве инструмента для управления программным потоком.

Прочитайте этот поток , если вы не уверены.