我写了一个函数来处理我的存储过程:

print 'Creating safeDivide Stored Proc ...'
go

if exists (select * from dbo.sysobjects where  name = 'safeDivide') drop function safeDivide;
go

create function dbo.safeDivide( @Numerator decimal(38,19), @divisor decimal(39,19))
   returns decimal(38,19)
begin
 -- **************************************************************************
 --  Procedure: safeDivide()
 --     Author: Ron Savage, Central, ex: 1282
 --       Date: 06/22/2004
 --
 --  Description:
 --  This function divides the first argument by the second argument after
 --  checking for NULL or 0 divisors to avoid "divide by zero" errors.
 -- Change History:
 --
 -- Date        Init. Description
 -- 05/14/2009  RS    Updated to handle really freaking big numbers, just in
 --                   case. :-)
 -- 05/14/2009  RS    Updated to handle negative divisors.
 -- **************************************************************************
   declare @p_product    decimal(38,19);

   select @p_product = null;

   if ( @divisor is not null and @divisor <> 0 and @Numerator is not null )
      select @p_product = @Numerator / @divisor;

   return(@p_product)
end
go

当错误传播回调用程序时，可以适当地处理它(如果需要，可以忽略它)。在c#中，SQL中发生的任何错误都会抛出一个异常，我可以捕获并在我的代码中处理，就像任何其他错误一样。

I agree with Beska in that you do not want to hide the error. You may not be dealing with a nuclear reactor but hiding errors in general is bad programming practice. This is one of the reasons most modern programming languages implement structured exception handling to decouple the actual return value with an error / status code. This is especially true when you are doing math. The biggest problem is that you cannot distinguish between a correctly computed 0 being returned or a 0 as the result of an error. Instead any value returned is the computed value and if anything goes wrong an exception is thrown. This will of course differ depending on how you are accessing the database and what language you are using but you should always be able to get an error message that you can deal with.

try
{
    Database.ComputePercentage();
}
catch (SqlException e)
{
    // now you can handle the exception or at least log that the exception was thrown if you choose not to handle it
    // Exception Details: System.Data.SqlClient.SqlException: Divide by zero error encountered.
}

用零代替“除零”是有争议的，但这也不是唯一的选择。在某些情况下，用1代替是(合理的)合适的。我经常发现自己吸毒

 ISNULL(Numerator/NULLIF(Divisor,0),1)

当我在看分数/计数的变化，并希望默认为1，如果我没有数据。例如

NewScore = OldScore *  ISNULL(NewSampleScore/NULLIF(OldSampleScore,0),1) 

通常情况下，我实际上在其他地方计算过这个比率(尤其是因为它可以为低分母提供一些非常大的调整因素)。在这种情况下，我通常控制OldSampleScore大于阈值;这就排除了零的可能性。但有时“hack”是合适的。

使用NULLIF(exp,0)，但以这种方式- NULLIF(ISNULL(exp,0)，0)

如果exp为空，NULLIF(exp,0)将中断，但NULLIF(ISNULL(exp,0)，0)将不会中断

添加一个CHECK约束，强制除数为非零 向表单添加验证器，以便用户不能在该字段中输入零值。

你至少可以阻止查询被错误打断，如果有被0除，返回NULL:

SELECT a / NULLIF(b, 0) FROM t 

然而，我永远不会像其他得到很多赞的答案那样，用合并将其转换为零。从数学意义上讲，这是完全错误的，甚至是危险的，因为您的应用程序可能会返回错误和误导性的结果。