在c#中如何在无效参数类型异常发生之前处理它

本文关键字：前处理 异常 参数 无效 类型 | 更新日期: 2023-09-27 18:12:25

在c#中如何处理无效参数类型异常

 static class calc
 {
    public static double subtract(double num1, double num2)
    {
        // I want to handle arguments exception here so whenever a nethod is called I can handle the exception
        return num1 - num2;
    }
  }

如果用户使用错误的参数类型，我想处理异常。

在c#中如何在无效参数类型异常发生之前处理它

在您的示例中，参数怎么可能是无效的?因为您声明了类型，所以值不可能无效。

我能想到的唯一的情况是，如果(num1 - num2) < Double.MinValue在这种情况下，这将导致一个错误。

在调用该方法之前，验证您传递的参数实际上是有效的类型。

或者，在调用周围使用try和Catch捕获异常。

    try 
    {
         //Call Method
         subtract(1.0,2.0);
    }
    catch (Exception ex)
    {
       throw new FaultException(ex.Message);
       // Or display a message box.  
    }

我认为这个方法失败的唯一方法是:

1)通过反射调用该方法，但使用了错误的参数。这不会是一个参数异常，因为问题将在"调用之外"。

2)使用double - double != double的参数调用函数。如果用户使用了错误的参数类型，这将不会是异常。为此，您可以对照double.Min检查您的参数:

static class calc
{
    public static double subtract(double num1, double num2)
    {
        double doubleAmountLeft = double.MaxValue - num1;
        if (num2 > num1)
        {
            throw new ArgumentOutOfRangeException("num2 > double.MaxValue - num1.");
        }
        return num1 - num2;
    }
}

你是指像这样的东西吗?

 static class calc
 {
    public static double subtract(double num1, double num2)
    {
        if (num1<num2) throw new ArgumentException("num1 < num2", "num2");
        return num1 - num2;
    }
  }

您甚至不能将其编译为接受非双精度或可转换为双精度的内容。然而，由于编译可能发生在执行附近(例如，当调用代码位于.aspx文件中时)，因此有时使用有一点意义。在这种情况下，使用一个接受object参数的表单也很方便，这样使用DataBinder.Eval的结果进行强制转换就不必在page上完成了:

static class Calc
{
  public static double Subtract(double num1, double num2)
  {
     return num1 - num2; //always correct type
  }
  public static double Substract(object num1, object num2)
  {
     try
     {
        return Subtract((double)num1, (double)num2);
        //alternatively allowing looser matching:
        //return Subtract(Convert.ToDouble(num1) - Convert.ToDouble(num2));
     }
     catch
     {
        throw new Exception("My Custom Exception Text");
     }
  }
}

坦率地说，我发现这比默认行为更令人困惑，如果我传递错误的类型从动态编译的代码像。aspx，因为我知道常见的异常比你更好。

相关文章：