|
I do a lot with ADO.net, and I use parameters as much as I can. Recently I was working on this method:
private static System.Data.IDbDataParameter
GetParameter
(
this System.Data.IDbCommand CMD
,
string Name
)
{
System.Data.IDbDataParameter result ;
if ( CMD.Parameters.Contains ( Name ) )
{
result = (System.Data.IDbDataParameter) CMD.Parameters [ Name ] ;
}
else
{
result = CMD.CreateParameter() ;
result.ParameterName = Name ;
CMD.Parameters.Add ( result ) ;
}
return ( result ) ;
}
It gets a parameter by name or creates one with the provided name if there isn't one already.
After a while I decided to change it to avoid the call to Contains (the getter and Add have to check for existence anyway) and use try/catch to detect the absence of the parameter:
private static System.Data.IDbDataParameter
GetParameter
(
this System.Data.IDbCommand CMD
,
string Name
)
{
System.Data.IDbDataParameter result ;
try
{
result = (System.Data.IDbDataParameter) CMD.Parameters [ Name ] ;
}
catch ( System.IndexOutOfRangeException err )
{
result = CMD.CreateParameter() ;
result.ParameterName = Name ;
CMD.Parameters.Add ( result ) ;
}
return ( result ) ;
}
And it was good.
Until today.
And Oracle.
Oracle.DataAccess.Client.OracleParameterCollection returns NULL when the parameter doesn't exist! 
I had to revert back to the earlier code. 
Edit: After a little more experimentation, I find that other ADO.net Providers I have handy also differ from Microsoft's lead -- four vendors, four outcomes. But, then again, MSDN doesn't say what should happen in this situation!
Anyway, I have since decided that the whole concept of the above code was a bad idea -- I know whether or not the parameter exists and I should act accordingly.
In any case, I rarely have to get a parameter by name -- it's a code smell.
Here, then, is an improved GetParameter (by Name), with no trying to Create and Add missing parameters -- I don't intend to call this when I know the parameter doesn't exist.
When a parameter doesn't exist, it is consistent in its behavior, so the caller can react effectively.
private static System.InvalidOperationException
GetParameterException
(
string Name
,
System.Exception Exception
)
{
Exception = new System.InvalidOperationException
(
"A Parameter with ParameterName '" + Name + "' is not contained by this ParameterCollection."
,
Exception
) ;
Exception.Data [ "ParameterName" ] = Name ;
return ( (System.InvalidOperationException) Exception ) ;
}
public static System.Data.IDbDataParameter
GetParameter
(
this System.Data.IDbCommand CMD
,
string Name
)
{
object result ;
try
{
result = CMD.Parameters [ Name ] ;
}
catch ( System.Exception err )
{
throw ( GetParameterException ( Name , err ) ) ;
}
if ( result == null )
{
throw ( GetParameterException ( Name , null ) ) ;
}
return ( (System.Data.IDbDataParameter) result ) ;
}
<rhetorical>
Why do Microsoft's implementations throw System.IndexOutOfRangeException ?
Do they simply iterate the collection until they find the item or hit the end? 
</rhetorical>
Edit 2 :
Ca.Ingres.Client.IngresCommand throws System.ArgumentOutOfRangeException
InterSystems.Data.CacheClient.CacheCommand throws System.IndexOutOfRangeException
MySql.Data.MySqlClient.MySqlCommand throws System.ArgumentException
modified 17-May-18 1:56am.
|
|
|
|
|
Oh, you are using Oracle?
Here is your problem!
|
|
|
|
|
I'm interested in the design decision to switch to exceptions when the existing method calls were working. Exceptions can be very expensive in .NET. Was it for some new feature that couldn't be "un-wound" and had to be hard-stopped via exception? Premature pseudo-optimization that went awry?
|
|
|
|
|
Yes, can be. Doesn't mean one should avoid using them.
Expensive Exceptions[^]
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Of course you shouldn't avoid using them when appropriate. Exceptions are for exceptional circumstances. Collection classes implement search/find methods because an item not being in the collection is not exceptional. Since searching or indexing into the collection has to occur anyways, the method saves time by returning a simple boolean rather than invoking the exception stack.
As you point out in your link though, if this is front-end code the user probably wouldn't notice even if they could generate 10,000 exceptions back-to-back. In that scenario it comes down to what you define as best practices.
With debugger: 42.4388 ms (contains) vs 69,055.0051 ms (exceptions)
Without debugger: 43.6290 ms (contains) vs 563.4023 ms (exceptions)
static void Main(string[] args)
{
int maxCount = 10000;
Random rng = new Random();
List<int> testList = new List<int>();
for (int i = 0; i < maxCount; i++)
testList.Add(i);
TimeSpan containsTest = TestCode(() =>
{
for (int i = 0; i < maxCount; i++)
testList.Contains(rng.Next(0, maxCount));
});
TimeSpan exceptionTest = TestCode(() =>
{
for (int i = 0; i < maxCount; i++)
{
try
{
rng.Next(0, maxCount);
throw new Exception();
}
catch (Exception)
{ }
}
});
Console.WriteLine($"Iterations: {maxCount}\nContains: {containsTest.TotalMilliseconds}\nExceptions: {exceptionTest.TotalMilliseconds}");
Console.ReadKey();
}
static TimeSpan TestCode(Action code)
{
Stopwatch sw = Stopwatch.StartNew();
code();
sw.Stop();
return sw.Elapsed;
}
|
|
|
|
|
Jon McKee wrote: Of course you shouldn't avoid using them when appropriate. Exceptions are for exceptional circumstances.
Doesn't look like they are only used in "exceptional" circumstances if I look at the .NET reference code 
Jon McKee wrote: Collection classes implement search/find methods because an item not being in the collection is not exceptional.
They can be exceptional; it depends on what the programmer (me) is expecting. If I specify an item from the collection over the index that doesn't exist, I'll get an exception.
Jon McKee wrote: Since searching or indexing into the collection has to occur anyways, the method saves time by returning a simple boolean rather than invoking the exception stack.
As you point out in your link though, if this is front-end code the user probably wouldn't notice even if they could generate 10,000 exceptions back-to-back. In that scenario it comes down to what you define as best practices.
Best practice means not to discourage the use of exceptions, simply because someone thinks that they slow the system. As you can see, it doesn't take much time to invoke the entire exception stack, as it can be done several thousand times in a second.
Too many idiots avoiding exceptions altogether and using booleans instead  If it is an error, throw an exception, it is that simple.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: If it is an error, throw an exception
We're not talking about errors though, an item not existing in a collection (in the specific code we're talking about) is not an error. If a situation is expected to happen you should be coding for it, not using exceptions. As already pointed out, raising exceptions is expensive so you should be careful to use them appropriately.
So you can check if an item exists using Contains and if it doesn't add it which is logically sound, you are dealing with all possible logic paths.
or
You can assume the item is there and if it isn't catch the exception and add the item in the exception handler which is logically unsound as the scenario where the item doesn't exist is an expected one, and this method is 10x slower.
It's a no-brainer in my opinion.
|
|
|
|
|
F-ES Sitecore wrote: We're not talking about errors though, an item not existing in a collection (in the specific code we're talking about) is not an error.
It IS if you reference an item in the collection that doesn't exist. Give it a try and you'll see an exception.
F-ES Sitecore wrote: If a situation is expected to happen you should be coding for it, not using exceptions.
That must be why File.Open doesn't throw any exceptions if you read a non-existing file 
The idea that one should avoid using exceptions is simply wrong. That's the reason you don't do a check before inserting; you rely on the exception-handling mechanism to handle the exceptional circumstance that there is a clash (or pk-violation, or any other constraint). It is a lot cleaner to handle any exception than it is to do a single check on each constraint, and a lot more efficient.
F-ES Sitecore wrote: You can assume the item is there and if it isn't catch the exception and add the item in the exception handler which is logically unsound as the scenario where the item doesn't exist is an expected one, and this method is 10x slower.
Whether or not the existence of the item is expected or unexpected is up to the programmer; lots of designs where I can safely assume the item to exist, and where it not existing WOULD be a logical error.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: It IS if you reference an item in the collection that doesn't exist.
If you're expecting it not to exist then don't reference it, check it exists first.
Contains = cheap
Exception = expensive
As I said, it's a no-brainer.
Eddy Vluggen wrote: The idea that one should avoid using exceptions is simply wrong.
No-one is saying that. We're saying in this specific context, the issue we're specifically discussing, using exceptions is the wrong solution. That doesn't mean using exceptions is always the wrong solution.
|
|
|
|
|
F-ES Sitecore wrote: Contains = cheap
Exception = expensive
As I said, it's a no-brainer.
Exceptions aren't expensive, and in case of an addition to a collection, it might be even cheaper to do a blind insert.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Exceptions aren't expensive,
Yes they are.
|
|
|
|
|
Throwing thousands is not what I call "expensive"; trying to shave of 1 ms because it is "faster" does not justify not using them.
And there are enough places where an exception is actually measurably cheaper than the alternative. I stated an example thereof; where are your arguments?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Throwing thousands is not what I call "expensive";
Your opinion isn't relevant, exceptions are considered to be expensive operations, they gather a lot of information that isn't needed if you're simply using it as a form of validation.
Two ways of doing something where one is 10 times quicker than the other, it's a no-brainer. Especially when we're talking websites that might have tens or hundreds of thousands of concurrent users; those 100ms here and there really add up.
Eddy Vluggen wrote: And there are enough places where an exception is actually measurably cheaper than the alternative.
That's a straw-man argument you keep coming back to. Again, no-one is saying that exceptions are never the proper solution, we are talking about a specific implementation.
|
|
|
|
|
F-ES Sitecore wrote: Your opinion isn't relevant,
Perhaps I should explain the difference between a measurable benefit and an opinion? 
F-ES Sitecore wrote: exceptions are considered to be expensive operations, they gather a lot of information that isn't needed if you're simply using it as a form of validation.
An insert is not a validation-routine. Yes, you can try to not use an exception, but if it complicates the code for an unmeasurable "speed optimization", you are still writing crappy code.
F-ES Sitecore wrote: Two ways of doing something where one is 10 times quicker than the other, it's a no-brainer. Especially when we're talking websites that might have tens or hundreds of thousands of concurrent users; those 100ms here and there really add up.
They do not "add up", unless you are using exceptions for simple logic.
F-ES Sitecore wrote: That's a straw-man argument you keep coming back to
That must be why you came up with the webserver-example 
F-ES Sitecore wrote: Again, no-one is saying that exceptions are never the proper solution, we are talking about a specific implementation.
Does this specific implementation contain your webserver?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: An insert is not a validation-routine. Yes, you can try to not use an exception, but if it complicates the code for an unmeasurable "speed optimization", you are still writing crappy code.
The code in question is regarding checking if an item is in a collection, ie it is validating the contents of the collection.
Eddy Vluggen wrote: if it complicates the code for an unmeasurable "speed optimization", you are still writing crappy code.
It does the opposite.
if (!data.Contains(i))
{
data.Add(i);
}
data[i].Value = x;
The above is clear to anyone who reads it what the rules and logic are.
try
{
data[i].Value = x;
}
catch
{
data.Add(i);
data[i].Value = x;
}
The above is less obvious, doesn't read as well and is more ambiguous.
So not using exceptions in this instance makes the code clearer and 10x faster. It's a no-brainer.
Eddy Vluggen wrote: They do not "add up", unless you are using exceptions for simple logic.
Which is what we're talking about; using exceptions to dictate predictable and expected logic flow.
|
|
|
|
|
F-ES Sitecore wrote: Which is what we're talking about; using exceptions to dictate predictable and expected logic flow.
Wasn't said in those words, so you could expect me to pound on the obvious. Also doesn't have anything to do with your webserver, does it?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It doesn't have anything to do with web servers, no. That was just an example of why performance gains can matter even if they are small. I know you're trying to drag the discussion away from the technical because your technical arguments have fallen flat.
|
|
|
|
|
F-ES Sitecore wrote: It doesn't have anything to do with web servers, no. That was just an example of why performance gains can matter even if they are small.
Which is why I already explained with a simple example that adding to a collection can be expensive; that's a strawman-argument as you will, but it isn't different from the webserver-example.
F-ES Sitecore wrote: I know you're trying to drag the discussion away from the technical because your technical arguments have fallen flat.
If it had, you'd be quoting it and explaining why 
But, I can always appreciate a thread were we argue for arguings sake 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: That must be why File.Open doesn't throw any exceptions if you read a non-existing file 
You're conflating contexts. Think of things from the perspective of the class. A File class' only purpose is to manipulate a file. Singular. A developer specifies a path. You have every expectation that file should exist. Now you're a Collection class. You handle an object set. Plural. A developer specifies an object. You have two options now: 1) the object set is well-defined, the object should exist, 2) the object set is not well-defined, the object might exist.
The big difference is that the Collection relies on the properties of the set while the File relies on the properties of the individual.
Eddy Vluggen wrote: Whether or not the existence of the item is expected or unexpected is up to the programmer
Collections are more abstractly complex than Files. The properties of the collection set itself determine the optimal (or only) approach. Not the developer.
Eddy Vluggen wrote: lots of designs where I can safely assume the item to exist, and where it not existing WOULD be a logical error.
Precisely my point. Each approach has a logical and/or mathematic[^] benchmark from which you can determine the appropriate approach[^].
Eddy Vluggen wrote: The idea that one should avoid using exceptions is simply wrong.
Agreed. Unless it's appropriate. In which case it's simply inefficient to use exceptions.
EDIT: Better words. The best words. Kappa.
modified 18-May-18 4:29am.
|
|
|
|
|
Jon McKee wrote:
You're conflating contexts. Think of things from the perspective of the class. A File class' only purpose is to manipulate a file. Singular. A developer specifies a path. You have every expectation that file should exist. Now you're a Collection class. You handle an object set. Plural. A developer specifies an object. You have two options now: 1) the object set is well-defined, the object should exist, 2) the object set is not well-defined, the object might exist.
The big difference is that the Collection relies on the properties of the set while the File relies on the properties of the individual.
Lots of nonsense.
Jon McKee wrote: Collections are more abstractly complex than Files.
So, a string is more complex than an Sql Server database-file now? And the string determines your approach?
Jon McKee wrote: Agreed. Unless it's appropriate. In which case it's simply inefficient to use exceptions.
The only example I have seen that could be called "inappropriate" is where a try-catch is if you use it for a single check. Whether it is efficient depends on how often an exception is raised.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Lots of nonsense.
Nah, was trying to simplify a thought and failed I guess. A File is a bad example because it accesses a collection at the end of the day too; it isn't truly singular.
I was attempting to explain that a collection, because it's a set of elements, has intrinsic properties that an element that isn't itself a collection doesn't have. These properties can (help) determine lots of design decisions including the best method of accessing elements of that collection. That's why File.Open throws exceptions yet File.Exists is still made available - they're for sets that have different properties. If you deal with a file or files which frequently don't exist, you can use that check instead of exceptions. If you deal with a file or files which almost always do exist, you can rely on exceptions.
|
|
|
|
|
Jon McKee wrote: If you deal with a file or files which frequently don't exist, you can use that check instead of exceptions.
If you expect that the file not might exist, then it not existing is not really something exceptional.
In an environment with a lot of people manipulating the FS, relying on the exception might be cheaper than doing the actual check (which might have race-conditions attached). In a database the difference can become more outspoken - depending on how much additional checks the database-server has to make.
Of course, on does not use an exception-handling routine instead of a logical if.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Best practice means not to discourage the use of exceptions, simply because someone thinks that they slow the system. As you can see, it doesn't take much time to invoke the entire exception stack, as it can be done several thousand times in a second.
I've seen a few exceptions that consumed viscerally measurable time, but they were thrown deep in the stack, but the first exception handler that could catch them was in or near the main routine, many layers up the call stack. Hence, there was a lot of stack to unwind.
Eddy Vluggen wrote: Too many idiots avoiding exceptions altogether and using booleans instead If it is an error, throw an exception, it is that simple.
Too many people being too lazy to use their God given brains as intended. Programming is, after all, all about thinking. Best practices are intended to serve as rules of thumb, not ironclad rules.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
An Exception that doesn't get thrown, costs nothing.
A double-check for something that exists, doubles your cost of retrieving it.
Looking up parameters by name is a costly operation either way, and it is easy enough to avoid anyway.
BUT, as I have to have such a method available, I choose to avoid the double-check.
I've been using ADO.net since 2002 and not until this week did I find a situation in which I might want to get a parameter by name.
(The method can be marked Obsolete with a message recommending the developer seek a better way.)
Any Exceptions thrown by such a lookup should be a sign of a bug. Once the bug is fixed, there will no longer be any attempts to retrieve a non-existent item -- at which point the double-check has the greater cost. If it makes sense for the calling code to check first, then that's a better place for the check.
|
|
|
|
|
I think you answered my question. Sounds like you have a well-defined set of values so not finding it is a rare occurrence. But what I was getting at is this:
private IDbDataParameter ExistsStuff(IDbCommand CMD, string Name) =>
(System.Data.IDbDataParameter) CMD.Parameters[Name];
private IDbDataParameter DoesntExistStuff(IDbCommand CMD, string Name)
{
IDbParameter result = CMD.CreateParameter() { ParameterName = Name };
CMD.Parameters.Add(result);
return result;
}
if (CMD.Parameters.Contains(Name))
result = ExistsStuff(CMD, Name);
else
result = DoesntExistStuff(CMD, Name);
try
{
result = ExistsStuff(CMD, Name);
}
catch ( System.IndexOutOfRangeException err )
{
result = DoesntExistStuff(CMD, Name);
}
In order to understand the differences, the statements they share in common were yanked out to normalize things. The main difference is as you said: the if front-loads the cost while the exception back-loads it. My other post[^] shows some code that tested Contains vs exceptions. Both that and another test I ran later using an invalid access to trigger the exception showed that exceptions are about 13 to 17 times as computationally expensive as a check.
Using that information, we can describe the functions mathematically. Shared code will be weighted as a 0 since it's shared (the code inside the if/try and else/catch). The if...else comes in at a weight of 1 for both branches since the check is required for both. The try...catch comes in at a weight of 0 for no exception and 15 for the exception branch. Now we'll use the variables x and y to denote the ratio that each branch is visited. Slap it all together and we get:
if/else: (1x + 1y)
try/catch: (0x + 15y)
Balance point: x + y = 15y => x = 14y => 1:14
This ratio shows that for the two methods to be equivalent x must occur 14 times as much as y. So for this example, 93.3% or more of the calls must generate no exception or you'd be better off with a check.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
