Der "richtige" Weg zur Überprüfung der gespeicherten Prozedurparameter

Question

Ich habe eine gespeicherte Prozedur, die eine Parametervalidierung durchführt und fehlschlagen und die Ausführung stoppen sollte, wenn der Parameter nicht gültig ist.

Mein erster Ansatz für die Fehlerprüfung sah wie folgt aus:

create proc spBaz 
(
    @fooInt int = 0, 
    @fooString varchar(10) = null, 
    @barInt int = 0, 
    @barString varchar(10) = null 
) 
as 
begin 
    if (@fooInt = 0 and (@fooString is null or @fooString = '')) 
    raiserror('invalid parameter: foo', 18, 0) 

    if (@barInt = 0 and (@barString is null or @barString = '')) 
    raiserror('invalid parameter: bar', 18, 0) 

    print 'validation succeeded' 
    -- do some work 
end 

Dies tat nicht den Trick seit Schwere 18 nicht die Ausführung stoppen und ‚Überprüfung erfolgreich‘ gedruckt wird, zusammen mit den Fehlermeldungen.

Ich weiß, dass ich einfach eine Rückkehr nach jedem raiserror hinzufügen könnte, aber das sieht irgendwie hässlich zu mir:

if (@fooInt = 0 and (@fooString is null or @fooString = '')) 
    begin 
    raiserror('invalid parameter: foo', 18, 0) 
    return 
    end 

    ... 

    print 'validation succeeded' 
    -- do some work 

Da Fehler mit Schweregrad 11 und höher innerhalb eines try/catch-Block einen anderen Ansatz gefangen ich getestet war, meine Fehlerprüfung innerhalb eines solchen try/catch-Blocks einzukapseln. Das Problem war, dass der Fehler verschluckt und nicht an den Client gesendet wurde. So habe ich einige der Forschung und fand einen Weg, um rethrow den Fehler:

ich mit diesem Ansatz immer noch nicht zufrieden bin so frag ich dich:

Wie sieht Ihre Parametervalidierung aus? Gibt es eine Art "Best Practice" für diese Art der Überprüfung?

Answer 1

Ich denke nicht, dass es einen einzigen "richtigen" Weg gibt, dies zu tun.

Meine eigene Präferenz wäre ähnlich wie in Ihrem zweiten Beispiel, aber mit einem separaten Validierungsschritt für jeden Parameter und expliziteren Fehlermeldungen.

Wie Sie sagen, es ist ein wenig umständlich und hässlich, aber die Absicht des Codes ist offensichtlich für jeden, der es liest, und es macht die Arbeit erledigt.

IF (ISNULL(@fooInt, 0) = 0) 
BEGIN 
    RAISERROR('Invalid parameter: @fooInt cannot be NULL or zero', 18, 0) 
    RETURN 
END 

IF (ISNULL(@fooString, '') = '') 
BEGIN 
    RAISERROR('Invalid parameter: @fooString cannot be NULL or empty', 18, 0) 
    RETURN 
END 

Answer 2

Wir normalerweise vermeiden Raiseerror() und einen Wert zurückgeben, der eine negative Zahl einen Fehler, beispielsweise zeigt:

if <errorcondition> 
    return -1 

oder das Ergebnis bei zwei Parameter übergeben:

create procedure dbo.TestProc 
    .... 
    @result int output, 
    @errormessage varchar(256) output 
as 
set @result = -99 
set @errormessage = null 
.... 
if <errorcondition> 
    begin 
    set @result = -1 
    set @errormessage = 'Condition failed' 
    return @result 
    end 

Answer 3

Ich ziehe es vor, so schnell wie möglich zurückzukehren, und sehe nicht darauf, dass alles am Ende des Verfahrens vom selben Punkt zurückkehrt. Ich habe diese Gewohnheit schon vor Jahren bei der Montage aufgenommen. Auch kehre ich immer einen Wert:

RETURN 10 

Die Anwendung wird einen fatalen Fehler auf positive Zahlen angezeigt werden, und die Benutzer Warnmeldung auf negative Werte angezeigt werden soll.

Wir geben immer einen OUTPUT-Parameter mit dem Text der Fehlermeldung zurück.

Beispiel:

IF ~error~ 
BEGIN 
    --if it is possible to be within a transaction, so any error logging is not ROLLBACK later 
    IF XACT_STATE()!=0 
    BEGIN 
     ROLLBACK 
    END 

    SET @OutputErrMsg='your message here!!' 
    INSERT INTO ErrorLog (....) VALUES (.... @OutputErrMsg) 
    RETURN 10 

END 

Answer 4

Wie Sie aus dieser Antwort Geschichte sehen folgte ich diese Frage und Antwort akzeptiert, und fuhr dann fort zu ‚erfinden‘ eine Lösung, die im Grunde die gleiche wie Ihre zweite Ansatz war.

Koffein ist meine Hauptquelle für Energie, aufgrund der Tatsache, dass ich die meiste Zeit meines Lebens im Halbschlaf verbringe, da ich viel zu viel Zeit mit der Codierung verbringe; So habe ich meinen Faux-pas erst bemerkt, als du es zu Recht darauf hingewiesen hast.

Daher bevorzuge ich Ihren zweiten Ansatz: Verwenden Sie einen SP, um den aktuellen Fehler zu erhöhen, und verwenden Sie dann einen TRY/CATCH um Ihre Parameterüberprüfung.

Es reduziert die Notwendigkeit für alle IF/BEGIN/END-Blöcke und reduziert daher die Anzahl der Zeilen und legt den Fokus wieder auf die Validierung. Beim Lesen des Codes für den SP ist es wichtig, die Tests zu sehen, die an den Parametern durchgeführt werden; der ganze zusätzliche syntaktische Fluff, um den SQL-Parser zu erfüllen, steht meiner Meinung nach nur im Weg.

Answer 5

Ich verwende immer Parameter @Is_Success Bit als OUTPUT. Wenn ich also einen Fehler habe, dann ist @ Is_success = 0. Wenn die übergeordnete Prozedur das @ Is_Success = 0 überprüft, setzt sie ihre Transaktion zurück (mit untergeordneten Transaktionen) und sendet eine Fehlermeldung von @Error_Message an den Client.