|
Mark Nischalke wrote: Not slowing it down.
Yes, slowing it down.
<Whoops, I hit post prematurely>
GUI.DoesTheKeyAlreadyExist?
BL.DoesTheKeyAlreadyExist?
API.DoesTheKeyAlreadyExist?
DAL.DoesTheKeyAlreadyExist?
SP.DoesTheKeyAlreadyExist?
DB.DoesTheKeyAlreadyExist?
How many times are you going to check the same darn thing when no problem exists? A duplicate key is an exceptional situation, whether you can test it or not.
Consider database round-trips to be very expensive.
</Whoops, I hit post prematurely>
Mark Nischalke wrote: If the key already exists return something like false
How do I know false means duplicate rather than timeout or a referential integrity violation?
|
|
|
|
|
Please, give me some credit. 
Of course I would not architect such a contrived situation as you have outlined. Neither would I expect false to mean everything. As I, and others, have been saying here, handle the known conditions but be prepared for other cases.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I believe Mark's argument is that, given that the described error condition is a likely occurrence, then the OP should code to detect and handle the condition directly, rather than rely on the exception mechanism (which is expensive).
Software Zen: delete this;
|
|
|
|
|
|
I was talking out of my hat, there. Generally speaking, exception mechanisms tend to be more expensive than normal control flow. In the SQL environment, that difference may be inconsequential compared to everything else that's going on.
Software Zen: delete this;
|
|
|
|
|
Just being awkward really 
As you say, whatever the code, the SQL hit is going to be the worst and swamp everything else. I agree with Mark's initial thoughts, you should avoid raising exceptions in the first place for the most part, but wouldn't vomit at the try/catch either ( I would avoid a re-throw though).
The one thing I don't think should enter the equation is the performance (ironically, given my post), until it is known that it will adversely impact the system. Early optimisation wrecks good clean code. If there are problems, they are likely to involve a small proportion of the code, which should be optimised as fully as possible. That's my hapney'sworth anyway.
|
|
|
|
|
Gary Wheeler wrote: the described error condition is a likely occurrence
No, it never happens; I've certainly never seen one outside of unit testing -- of exception handling.
|
|
|
|
|
Exactly the point. The application should be designed and coded so that it is an exceptional situation when it occurs. When responding to OP the first option given was to allow the exception to occur, which, IMO, is not correct, it should have been emphasized to correct the problem before it occurs or take other mitigating actions before just accepting the exception.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Uhm, his suggestion sounds pretty good to me.
try
{
// code that attempts an insert
}
catch ( some exception)
{
// show error message to the user about how that key exists
}
What's the big deal?
|
|
|
|
|
I have always been taught and follow the principle that conditions that can be tested for are not exceptions and you shouldn't use exception handling for them. Certainly there are cases you can't test for or don't expect to happen. In this particular case the unique key violation is expected and can be tested for.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Mark Nischalke wrote: I have always been taught and follow the principle that conditions that can be tested for are not exceptions and you shouldn't use exception handling for them. Certainly there are cases you can't test for or don't expect to happen. In this particular case the unique key violation is expected and can be tested for.
If this collision is a rarely occurring one or even an infrequently occurring one, I'd always just go ahead and try and insert and then catch any exception. I wouldn't run an extra database trip just to avoid catching an exception so my code is compatible with somebody's idea of a perfect design.
|
|
|
|
|
Yes, hence my statement, "cases you can't test for or don't expect to happen", I should have added, or happen often.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Okay. But why did you pick on the guy like this? He gave 3 alternate solutions, only one of which suggested catching the database exception. It seemed as if you were looking for a fight here
|
|
|
|
|
I wasn't "picking" on anyone nor did I criticize his perfectly valid solutions. His last response struck me as one who can't explain his position so comes back with playground response of "I know you are but what am I"
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Okay, but I just thought both of you (not just him) kinda went the "immature" route towards the end there.
|
|
|
|
|
Fair enough. Regardless, this is a good discussion.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Mark Nischalke wrote: Regardless, this is a good discussion.
Oh yes, in fact I wish we had more of these in the Lounge 
|
|
|
|
|
In principal you are correct. But remember that exceptions are there for exceptional cases; pun intented.
In the case of creating a new record where you expect the key to be unique, I agree with the others that using an exception is the correct approach. If there is a good chance that the key will not be unique then a different approach would be justified. There I would try to read the record with the key, if it does not exist then I would do the insert. I would however still have the try/catch on the insert.
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
|
|
|
|
|
Nagy Vilmos wrote: But remember that exceptions are there for exceptional cases
Yes, exactly for exceptional cases. I would use TryParse rather than Try/Catch but be prepared for UnhandledExceptions.
Nagy Vilmos wrote: If there is a good chance that the key will not be unique then a different approach would be justified. There I would try to read the record with the key, if it does not exist then I would do the insert. I would however still have the try/catch on the insert.
Agreed. But the Try/Catch is to catch unexpected cases not the normal flow.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Mark Nischalke wrote: conditions that can be tested for
Do you check your car's battery charge, tire pressure, tread depth, lug nut torque, etc. every time you leave the house? Do you check your fly before leaving the men's room? Do you wear a belt and suspenders?
Just being able to perform a test, doesn't make it worthwhile.
|
|
|
|
|
If I expected my nuts to be loose I certainly would check my fly.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I'm not sure, but doesn't Sql Server throw a SqlException in these cases? The catch-all could hide conversion-errors, or index-out-of-bounds exceptions.
It's still best to try to be specific about the type of exception that you're trying to handle.
I are Troll 
|
|
|
|
|
Yes only a SqlException is thrown, then you look at the number to determined the type of underlying Exception
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Eddy Vluggen wrote: I'm not sure, but doesn't Sql Server throw a SqlException in these cases? The catch-all could hide conversion-errors, or index-out-of-bounds exceptions.
Yeah, no one here has recommended a catch-all. What was recommended was to catch the specific exception thrown (which depends on what mechanism you are using to talk to the database).
My take on this is that there are no hard and fast rules for things like this. In general, I just try and stick to some consistent practices on a project and these practices themselves may not be identical across multiple projects.
|
|
|
|
|
Nishant Sivakumar wrote: Yeah, no one here has recommended a catch-all
Sorry, I get religious when I see one of those - it comes close to an "on whatevererror resume here".
Nishant Sivakumar wrote: My take on this is that there are no hard and fast rules for things like this
There's this article on CodeProject[^] that seems to suggest that it wouldn't cost much in terms of performance.
An exception that gets eaten OTOH, might be very costly.
Nishant Sivakumar wrote: I just try and stick to some consistent practices on a project and these practices themselves may not be identical across multiple projects.
True. Hell, I'll even color-code the exceptions if there's a compelling reason
I are Troll
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
