Exception Handling better in Db or in c# code?

Question

I have a stored procedure to insert data in SQL Server DB. I'm using WCF Service which takes data from client and inserts data in the DB. I have a unique key constraint on Name column of my DB table.

If there is any unique key constraint errors:

1. I handle that in Stored Procedure. eg using if exists statement in SQL Server and if value is there then I should return -1 otherwise it should insert row in db.

2. I handle that in my (WCF Service)c# code. I get sql exception and return that sql exception code to the client.

In the first solution I think there is performance issue, because unique key constraint will be checked 2 times. First time I'm checking it manually within stored procedure and second time unique key constraint will check it again. So, 1 value is being checked twice.

In second solution exception is being handle by wcf service using c# code and I've heard exceptions in wcf is not so good.

What's the best solution?

Answer 1

"Better" is a little bit subjective here, and it kinds of depends on which "better" you like.

• If you mean from a performance perspective, I'd be willing to bet that Option 1 is actually more performant, since the process of checking an index for an existing value in SQL Server (even twice) will probably be dwarfed by the time it takes to raise and propagate an exception back into your code. (Not to mention that you don't have to check it twice at all, you can try/catch in T-SQL itself and return -1 on a Unique key violation)

• However if you mean from a design and maintenance point of view, then Option 2 is in my opinion far more desirable, since it is very clear what is going on

In other words, as a developer I would rather read (pseudo-code)

//assuming you have a connection open, a command prepared, etc.
try
{
    var result=command.ExecuteNonQuery();
}
catch(SqlException ex)
{
    if(ex.Number==2627)
    {
        //Unique Key constraint violation.
        //Error 2627 is documented and well known to be a Unique Key Constraint Violation 
       //so it's immediately obvious what's going on here
    } 
}

than

var result=command.ExecuteNonQuery();
if (result==-1)
{
   //this means a unique key violation
   //what if that comment got removed? I'd have no clue what
   //-1 meant...
}

Even though at first glance the second is shorter and more succint.

Note: as MetroSmurf pointed out, catching the exception here is not ideal, it should be handled by the caller, so this is just for illustrative purposes.

This is because the -1 here is pretty arbitrary on the part of the stored procedure; so unless you can guarantee that you can document it and that this document will never go out of date ,etc, then you could be placing the burden on the next developer to have to go look up the Stored Procedure, and figure out what exactly -1 means in this context.

Plus since it's possible for someone to change the SP without touching your C#, what are you going to do if the SP suddenly starts returning "42" for Unique Key Violations? Of course you may be in full control of the SP but will that always be the case?