Плохая идея отбросить ex.InnerException?

Question

По сути, мой вопрос короток и приятен: является ли следующая плохая идея (инкапсуляция и отбрасывание ex.InnerException вместо ex)

(здесь есть похожий вопрос , но не совсем ... Я хочу повторно инкапсулировать InnerException, чтобы трассировка стека сохранялась без учета внутренних элементов)

public abstract class RpcProvider
{
    public virtual object CallMethod(string methodName, params object[] parameters)
    {
        MethodInfo mi = this.GetType().GetMethod(methodName);

        if (mi == null || mi.GetCustomAttributes(typeof(RpcCallAttribute), true).Length == 0)
        {
            throw new NotImplementedException("This method is not provided by this RPC provider.");
        }
        else
        {
            try
            {
                return mi.Invoke(this, parameters);
            }
            catch (TargetInvocationException ex)
            {
                throw new RpcException("There was an error in the RPC call. See the InnerException for details.", ex.InnerException);
            }
        }
    }
}

Приведенная ниже трассировка стека кажется исправной и безупречной (ну, это без внутренних деталей того, как отражение вызывает метод), так есть ли вообще проблема с этим? Чтобы описанная ниже трассировка стека имела смысл, моя иерархия наследования:

 -Oxide.Net.Rpc.RpcProvider
 |-Oxide.Net.Rpc.XmlRpc
  |-StartMenuSorter.DesktopMasters

(sanitised to protect the innocent, ie. me)

at Oxide.Net.Rpc.XmlRpc.DoRequest(Uri rpcConnectionUri, IXPathNavigable request, String userAgent) in \Projects\OxideLib\Oxide.Net\Rpc\XmlRpc.cs:line 243
at StartMenuSorter.DesktopMasters.GetIconInformation(IEnumerable`1 icons) in \Projects\StartMenuSorter\StartMenuSorter\DesktopMasters.cs:line 17
at Oxide.Net.Rpc.RpcProvider.CallMethod(String methodName, Object[] parameters) in \Projects\OxideLib\Oxide.Net\Rpc\RpcProvider.cs:line 52
at StartMenuSorter.Program.Main() in \Projects\StartMenuSorter\StartMenuSorter\Program.cs:line 36
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()

Answer 1

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

Как и во всем коде обработки ошибок, конечным потребителем будут другие разработчики, поэтому было бы неплохо спросить: "У меня достаточно деталей, чтобы отладить это самостоятельно, если что-то пойдет не так?"

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

Answer 2

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

Answer 3

Я делал это раньше; это сработало довольно хорошо для меня, и это была та же форма, которую вы использовали в своем примере.