Обработка ошибок VBScript в C # - PullRequest
       19

Обработка ошибок VBScript в C #

2 голосов
/ 30 сентября 2011

Я хочу получить доступ к WMI, используя AutomationFactory в приложении Silverlight OOB.

dynamic locator = AutomationFactory.CreateObject("WbemScripting.SWbemLocator");
dynamic wmi = locator.ConnectServer(".", "\\root\\cimv2");

Теперь я хочу добавить к этому обработку ошибок.

MSDN указывает, что возвращаемое значение является ссылкой на подключенный объект, если вызов успешен, и что в случае ошибки я должен проверить объект Err.Однако у меня есть два вопроса:

  • Какое возвращаемое значение, если вызов не был успешным?ноль?Какой-то произвольный указатель, который я не могу использовать?
  • Как я могу получить доступ к объекту Err в Silverlight?
  • Как определить, был ли вызов успешным?Могут ли быть какие-то исключения, которые я должен перехватить?
  • Я видел несколько примеров с использованием оператора using, а некоторые без него.Нужно ли утилизировать динамические объекты вручную после их использования?

1 Ответ

1 голос
/ 30 сентября 2011
  • Какое возвращаемое значение, если вызов не был успешным?ноль?Какой-то произвольный указатель, который я не могу использовать?

Никакое значение не возвращается, и LHS назначения не изменяется при сбое вызова в компонент COM.Вместо этого выдается COMException.

  • Как получить доступ к объекту Err в Silverlight?

Это не "ошибка"объект, то есть конструкция VB (Script), он не существует в C #.Однако информация, которую вы запрашиваете, будет доступна в качестве свойств COMException, генерируемых при сбое вызова.

  • Как определить, был ли вызов успешным?Могут ли быть какие-то исключения, которые я должен поймать?

Да, см. Выше.

  • Я видел несколько примеров использования using заявление, а некоторые без.Нужно ли удалять динамические объекты вручную после их использования?

Попытки управлять временем жизни COM-объектов с помощью Dispose приводят к различным результатам.Лично я позаботился о том, чтобы все, что имеет что-то вроде метода «Закрыть», имело этот вызов метода «Закрыть», и оставил бы это в покое.

Если вы действительно хотите, чтобы пользовательские COM-объекты были освобождены, то в соответствующий момент (и не слишком часто) вызовите GC.Collect.

...