Различие между переброском выгоды без параметров и не выполнением чего-нибудь?

Вы можете попробовать следующее:

names.vec = sapply(mapping, unlist)[2,]
> names.vec
[1] "bob"       "alice"     "mark"      "simon"     "jeff"      "alexander"

Затем назначьте их как имена столбцов вашей матрицы

colnames(my_matrix) = names.vec

, используя первые 6 записей данных вашего примера:

[ 112]
14
задан JaredPar 4 April 2009 в 17:50
поделиться

10 ответов

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

    public void Foo()
    {
        try
        {
            // Some service adapter code

            // A call to the service
        }
        catch (ServiceBoundaryException)
        {
            throw;
        }
        catch (Exception ex)
        {
            throw new AdapterBoundaryException("some message", ex);
        }
    }

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

7
ответ дан 1 December 2019 в 12:39
поделиться

Да существует различие. При ловле исключения.NET предполагает, что Вы собираетесь обработать ее в некотором роде, стек раскручен до функции, которая делает выгоду.

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

Таким образом, если Вы ловите, затем повторно бросают исключение, которое не обработано в другом месте, Вы отнимаете у инструмента диагностики действительно полезной информации о том, что на самом деле произошло.

3
ответ дан 1 December 2019 в 12:39
поделиться

Взятый как есть, первая опция походила бы на плохое (или это должно быть 'бесполезно'?) идея. Однако это редко делается этот путь. Исключения обычно повторно бросаются из блока Выгоды при двух условиях:

a. Вы хотите проверить исключение, сгенерированное на данные и условно пузыриться он стек.

try 
{
  //do something
}
catch (Exception ex)
{
  //Check ex for certain conditions.
  if (ex.Message = "Something bad")
    throw ex;
  else
    //Handle the exception here itself.
}

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

try 
{
  //do something
}
catch (StackOverflowException ex)
{
    //Bubble up the exception to calling code 
    //by wrapping it up in a custom exception.
    throw new MyEuphemisticException(ex, "Something not-so-good just happened!");
}
3
ответ дан 1 December 2019 в 12:39
поделиться

Просто перебросок не имеет никакого смысла - это - то же, как будто Вы ничего не сделали.

Однако становится полезным, когда Вы на самом деле делаете что-то - наиболее распространенная вещь состоит в том, чтобы зарегистрировать исключение. Можно также изменить состояние класса, безотносительно.

2
ответ дан 1 December 2019 в 12:39
поделиться

Никогда не делайте опцию A. Как Anton говорит, это съедает отслеживание стека. Пример JaredPar также съедает stacktrace. Лучшее решение было бы:

SomeType* pValue = GetValue();
try {
  // Do Something
} finally {
  delete pValue;
}

Если Вы получили что-то в C#, который должен быть выпущен, например, FileStream, Вы получили следующие два варианта:

FileStream stream;
try
{
  stream = new FileStream("C:\\afile.txt");
  // do something with the stream
}
finally
{
  // Will always close the stream, even if there are an exception
  stream.Close(); 
}

Или более чисто:

using (FileStream stream = new FileStream("c:\\afile.txt"))
{
  // do something with the stream
}

Используя оператор Расположит (и близко) поток при выполнении или когда исключение закрывается.

1
ответ дан 1 December 2019 в 12:39
поделиться

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

Resource r = GetSomeResource();
try {
  // Do Something
} catch { 
  FreeSomeResource();
  throw;
}
FreeSomeResource();

Однако нет никакого основного назначения в выполнении его этот путь. Было бы намного лучше просто использовать наконец блок вместо этого.

2
ответ дан 1 December 2019 в 12:39
поделиться

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

1
ответ дан 1 December 2019 в 12:39
поделиться

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

public class XmlException: Exception{
   ....
} 

public class XmlParser{
   public void Parse()
   {
      try{
          ....
      }
      catch(IOException ex)
      {
         throw new XmlException("IO Error while Parsing", ex );
      }
   }
}

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

1
ответ дан 1 December 2019 в 12:39
поделиться

Блок - выгода попытки - блок не имеет никакого смысла мне. Я полагаю что, если Вы не собираетесь обрабатывать исключение, затем почему Вы ловите те исключения.. Это было бы так или иначе брошено в следующий уровень.

Но, если Вы создаете средний уровень API или что-то как этот и обрабатываете исключение (и следовательно съедаете исключение) в том слое, не имеет смысла, затем можно бросить собственный уровень ApplicationException. Но конечно перебросок того же исключения не имеет смысла.

1
ответ дан 1 December 2019 в 12:39
поделиться

Так как классы находятся в 2 различных блоках, можно хотеть o, просто ловят исключение для входа его и затем отбрасывают его назад вызывающей стороне, так, чтобы это могло обработать его способ, которым это считает целесообразным. Бросок вместо броска исключая сохранит контекстную информацию о где порожденное исключение. Это может оказаться полезным, когда Вашим блоком является API/платформа, где в Вас никогда не должен глотать исключения, если его значимое, чтобы сделать так, но полезный, тем не менее, в стрельбе проблемы, если это зарегистрировано, например, к EventLog.

1
ответ дан 1 December 2019 в 12:39
поделиться
Другие вопросы по тегам:

Похожие вопросы: