|
From now on, I will use that as an insult. Isomorphic Git just sounds way better than poopy-head.
|
|
|
|
|
|
Nice. Exactly what I always wanted!  
|
|
|
|
|
Yup. Sure beats sliced bread.
... such stuff as dreams are made on
|
|
|
|
|
I was thinking IoT Toaster. But that would work too! 
|
|
|
|
|
|
Lol! That's what I am talking about! 
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
