Je crois qu'il y a quelques exceptions, mais à partir des gravités d'erreur du moteur de base de données (MSDN) :
Les messages d'erreur avec un niveau de gravité de 19 ou supérieur arrêtent l'exécution du lot en cours.
Les erreurs qui mettent fin à la connexion à la base de données, généralement avec une gravité de 20 à 25, ne sont pas gérées par le bloc CATCH car l'exécution est abandonnée à la fin de la connexion.
Il semble donc que vous puissiez obtenir une liste définitive de la requête suivante (bien sûr, cela ne vous permettra pas de filtrer celles qui peuvent être causées par l'utilisateur T-SQL):
SELECT message_id, severity, [text]
FROM sys.messages
WHERE language_id = 1033
AND severity >= 19
ORDER BY severity, message_id;
Dans SQL Server 2012, cela produit 210 lignes.
Dans SQL Server 2016, cela produit 256 lignes.
Soit dit en passant, je ne crois pas que les deux scénarios que vous décrivez dans votre question fonctionnent comme vous le pensez, du moins pas dans les versions modernes de SQL Server. J'ai essayé cela à la fois sur 2012 et 2016 (je crois que l'article d'Erland décrit le comportement de SQL Server 2000, dont je ne me souviens pas s'il était différent, mais pas très pertinent aujourd'hui, même si c'est le cas).
USE tempdb;
GO
CREATE PROCEDURE dbo.pA -- no parameters
AS PRINT 1
GO
CREATE PROCEDURE dbo.pB -- two parameters
@x INT, @y INT
AS PRINT 1
GO
SET XACT_ABORT OFF;
GO
EXEC dbo.pA @foo = 1;
PRINT '### Calling procedure that doesn''t take parameters with a parameter';
GO
EXEC dbo.pB;
PRINT '### Calling procedure that takes 2 parameters with no parameters';
GO
EXEC dbo.pB @x = 1;
PRINT '### Calling procedure that takes 2 parameters with not enough parameters';
GO
EXEC dbo.pB @x = 1, @y = 2, @z = 3;
PRINT '### Calling procedure that takes 2 parameters with too many parameters';
GO
Tous ces éléments produisent des erreurs de niveau de gravité 16, et tous continuent avec le lot, comme en témoigne la sortie d'impression:
Msg 8146, niveau 16, état 2, procédure pA, ligne 11 La
procédure pA n'a aucun paramètre et aucun argument n'a été fourni.
### Procédure d'appel qui ne prend pas de paramètres avec un paramètre
Msg 201, niveau 16, état 4, procédure pB, ligne 14 La
procédure ou la fonction 'pB' attend le paramètre '@x', qui n'a pas été fourni.
### Procédure d'appel qui prend 2 paramètres sans paramètres
Msg 201, niveau 16, état 4, procédure pB, ligne 18 La
procédure ou la fonction 'pB' attend le paramètre '@y', qui n'a pas été fourni.
### Procédure d'appel qui prend 2 paramètres avec pas assez de paramètres
Msg 8144, niveau 16, état 2, procédure pB, ligne 22 La
procédure ou la fonction pB a trop d'arguments spécifiés.
### Procédure d'appel qui prend 2 paramètres avec trop de paramètres
Comme je le soupçonnais, il y a des exceptions, bien sûr, comme indiqué dans les commentaires. L'échec de la conversion est de gravité 16 mais abandonne le lot:
SET XACT_ABORT OFF;
SELECT CONVERT (INT, 'foo');
PRINT 'Made it.'; -- no print happens
Les résultats n'incluent pas la sortie d'impression cette fois:
Msg 245, niveau 16, la
conversion de l' état 1 a échoué lors de la conversion de la valeur varchar 'foo' en type de données int.