Я бы сделал это так с конструктором String и PadLeft :
Dim d As New System.Text.StringBuilder
For y = 0 To NumericUpDownY.Value
If y < NumericUpDownY.Value Then
d.AppendLine(New String("#", NumericUpDownX.Value + 1))
Else
d.AppendLine("X".PadLeft(NumericUpDownX.Value + 1, "#"))
End If
Next
output.Text = d.ToString
Если вы хотите что-то более встроенное в то, что вы делали изначально затем:
Dim d As String = ""
For y = 0 To NumericUpDownY.Value
For x = 0 To NumericUpDownX.Value
If y = NumericUpDownY.Value AndAlso x = NumericUpDownX.Value Then
d = d & "X"
Else
d = d & "#"
End If
Next
d = d & vbCrLf
Next
output.Text = d
Вы должны выбросить исключения. Исключения отображаются в HRESULTS платформой, а HRESULT являются стандартным способом возврата ошибок COM-клиентам, так что это путь.
Каждый тип исключения имеет свойство HResult. Когда управляемый код, вызываемый из COM-клиента, генерирует исключение, среда выполнения передает HResult COM-клиенту. Если вам нужны специфичные для приложения коды HRESULT, вы можете создать свои собственные типы исключений и установить свойство Exception.HResult .
Следует отметить, что информация стека вызовов будет потеряна при исключении выбрасывается на COM-клиент. Поэтому может быть хорошей идеей регистрировать исключения перед распространением на COM-клиент.
Одна из техник, которые я иногда использую, заключается в следующем: явно реализовать интерфейс ComVisible для клиентов COM, который регистрирует и перебрасывает исключения. COM-клиенты используют интерфейс ComVisible, который регистрирует исключения перед их распространением. Клиенты .NET используют конкретный класс и, как ожидается, сами примут меры для обработки исключений. Писать немного скучно, но это может пригодиться при последующем устранении неполадок.
Еще одним преимуществом этого подхода является то, что вы можете иметь API, адаптированный к ограничениям COM для клиентов COM, и более стандартный API для стандартные .NET клиенты. Например, клиенты COM ограничены передачей массивов по ссылке, тогда как передача по ссылке не рекомендуется для клиентов .NET.
Пример:
[
ComVisible(true),
GuidAttribute("..."),
Description("...")
]
public interface IMyComVisibleClass
{
// Text from the Description attribute will be exported to the COM type library.
[Description("...")]
MyResult MyMethod(...);
[Description("...")]
MyOtherResult MyArrayMethod([In] ref int[] ids,...);
}
...
[
ComVisible(true),
GuidAttribute("..."),
ProgId("..."),
ClassInterface(ClassInterfaceType.None),
Description("...")
]
public class MyComVisibleClass : IMyComVisibleClass
{
public MyResult MyMethod(...)
{
... implementation without exception handling ...
}
public MyOtherResult MyArrayMethod(int[] ids,...)
{
... input parameter does not use ref keyword for .NET clients ...
... implementation without exception handling ...
}
MyResult IMyComVisibleClass.MyMethod(...)
{
// intended for COM clients only
try
{
return this.MyMethod(...);
}
catch(Exception ex)
{
... log exception ...
throw; // Optionally wrap in a custom exception type
}
}
MyOtherResult IMyComVisibleClass.MyArrayMethod(ref int[] ids, ...)
{
// intended for COM clients only
try
{
// Array is passed without ref keyword
return this.MyArrayMethod(ids, ...);
}
catch(Exception ex)
{
... log exception ...
throw; // Optionally wrap in a custom exception type
}
}
}
Я согласен с остальными, что это не ответ «да или нет», не зная вашего проекта.
Это будет зависеть от ряда факторов, таких как:
Вот хороший пост в блоге в котором обсуждается ряд тонких моментов, касающихся обработки исключений.
Автор рекомендует один из двух подходов:
Либо:
, либо:
Лично я думаю, что вам следует избегать тесной связи службы C # с приложением C ++. Другими словами, напишите свой сервис на C #, чтобы теоретически его мог использовать любой потребитель. Аналогично, ваш код C ++ должен быть написан так, чтобы он не зависел от внутренней работы службы C #, поэтому изменения или дополнения к исключениям (или кодам ошибок) не нарушают потребителя.
Я думаю, это зависит от того, как унаследованное приложение будет реагировать. Если он понимает возвращаемые значения ошибок, тогда используйте этот подход. Если этого не произойдет, вам придется генерировать исключения и надеяться, что они обрабатывают их соответствующим образом.
Кроме того, если это неправильная ссылка (например, нулевая ссылка) или другая критическая ошибка, я бы всегда выдавал исключение. Однако следует избегать исключений для вещей, которые потребитель не может проверить заранее (например, поиск, который появляется пустым, не должен вызывать исключение).
Если ваше COM-приложение поддерживает интерфейсы IErrorInfo при вызове в службу C #, и это полностью внутренний проект, тогда выбрасывать исключения, вероятно, лучшая ставка, поскольку она собирает большую часть информации. Однако COM традиционно полагался на результаты HR для передачи результатов статуса и может быть лучше, если услуга будет опубликована в других источниках.
РЕДАКТИРОВАТЬ: Мне больше нравится ответ Джо.
Лучшим судьёй, будете ли вы использовать исключения или возвращаемые значения, будете ВЫ. «Выдача исключений» перевешивает «возвращаемые значения» несколькими способами. НО в некоторых случаях возвращаемых значений будет достаточно.