Бездействие над трассировкой стека на самом деле не звучит как хорошая идея, даже если это возможно (я сомневаюсь в этом). Скажи мне, почему ты так хочешь? Сама платформа .NET (BCL) часто использует статические служебные методы для генерации исключений, как вы и предлагаете (ThrowHelper
- это его имя по крайней мере в некоторых частях платформы), и, безусловно, что-то скрывает в стеке след.
Вот пример трассировки стека из теста, который я только что выполнил:
at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
at System.ThrowHelper.ThrowArgumentOutOfRangeException()
at System.Collections.Generic.List`1.get_Item(Int32 index)
at HelloWorld.Program.Main(String[] args) in C:\...\Program.cs:line 23
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
Как видите, BCL использует метод ThrowArgumentOutOfRangeException
, и он четко виден в трассировке стека. Если вы хотите пометить вспомогательный метод атрибутом DebuggerNonUserCode
, то это будет достаточно справедливым для меня (хотя в BCL это не сделано).