编辑: 最近我得到了很多反对票…所以我想我只是添加了一个注释，这个答案是在问题经历了最近的编辑之前写的，返回null作为一个选项被高亮显示…这似乎是可以接受的。我的一些回答是针对Edwardo的担忧，在评论中，他似乎主张返回0。这就是我反对的案子。

答: 我认为这里有一个潜在的问题，即除以0是不合法的。这表明某些事情从根本上是错误的。如果你在除以0，你在尝试做一些数学上没有意义的事情，所以你得到的数字答案都是无效的。(在这种情况下使用null是合理的，因为它不是一个将在以后的数学计算中使用的值)。

所以Edwardo在评论中问道:“如果用户输入一个0呢?”他主张得到一个0应该是可以的。如果用户在金额中输入0，并且您希望在他们这样做时返回0，那么您应该在业务规则级别放入代码以捕获该值并返回0…没有一些特殊情况，除以0 = 0。

这是一个微妙的区别，但很重要……因为下次有人调用你的函数并希望它做正确的事情时，它做了一些奇怪的事情，从数学上来说是不正确的，但只是处理特定的边界情况，它有很好的机会在以后咬人。你不是真的除以0…你只是对一个糟糕的问题给出了一个糟糕的答案。

想象一下，我在写代码，结果搞砸了。我应该读取辐射测量缩放值，但在一个我没有预料到的奇怪边缘情况下，我读取的是0。然后我将我的值放入你的函数中…你给我一个0!万岁，没有辐射!除了它真的在那里，只是我传入了一个坏的值…但我不知道。我想让除法抛出错误因为它是出错的标志。

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

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

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

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

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

CREATE FUNCTION dbo.Divide(@Numerator Real, @Denominator Real)
RETURNS Real AS
/*
Purpose:      Handle Division by Zero errors
Description:  User Defined Scalar Function
Parameter(s): @Numerator and @Denominator

Test it:

SELECT 'Numerator = 0' Division, dbo.fn_CORP_Divide(0,16) Results
UNION ALL
SELECT 'Denominator = 0', dbo.fn_CORP_Divide(16,0)
UNION ALL
SELECT 'Numerator is NULL', dbo.fn_CORP_Divide(NULL,16)
UNION ALL
SELECT 'Denominator is NULL', dbo.fn_CORP_Divide(16,NULL)
UNION ALL
SELECT 'Numerator & Denominator is NULL', dbo.fn_CORP_Divide(NULL,NULL)
UNION ALL
SELECT 'Numerator & Denominator = 0', dbo.fn_CORP_Divide(0,0)
UNION ALL
SELECT '16 / 4', dbo.fn_CORP_Divide(16,4)
UNION ALL
SELECT '16 / 3', dbo.fn_CORP_Divide(16,3)

*/
BEGIN
    RETURN
        CASE WHEN @Denominator = 0 THEN
            NULL
        ELSE
            @Numerator / @Denominator
        END
END
GO

SELECT Dividend / ISNULL(NULLIF(Divisor,0), 1) AS Result from table

通过使用nullif()捕获零，然后使用isnull()捕获结果为零，可以避免除零错误。

There is no magic global setting 'turn division by 0 exceptions off'. The operation has to to throw, since the mathematical meaning of x/0 is different from the NULL meaning, so it cannot return NULL. I assume you are taking care of the obvious and your queries have conditions that should eliminate the records with the 0 divisor and never evaluate the division. The usual 'gotcha' is than most developers expect SQL to behave like procedural languages and offer logical operator short-circuit, but it does NOT. I recommend you read this article: http://www.sqlmag.com/Articles/ArticleID/9148/pg/2/2.html

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

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