Is it my fault?

PIEBALDconsult

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! :mad::mad::mad: I had to revert back to the earlier code. :sigh: 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

Super Lloyd

Oh, you are using Oracle? Here is your problem! :omg:

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

Jon McKee

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?

Lost User

Yes, can be. Doesn't mean one should avoid using them. Expensive Exceptions[^]

Bastard Programmer from Hell :suss: 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.

Jon McKee

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 testList = new List();
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;
}

Lost User

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.

Bastard Programmer from Hell :suss: 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.

Lost User

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 :thumbsup: If it is an error, throw an exception, it is that simple.

Bastard Programmer from Hell :suss: 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.

F ES Sitecore

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.

Lost User

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 :rolleyes: 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 :suss: 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.

F ES Sitecore

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.

Lost User

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. :thumbsup:

Bastard Programmer from Hell :suss: 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.

F ES Sitecore

Eddy Vluggen wrote:

Exceptions aren't expensive,

Yes they are.

Lost User

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 :suss: 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.

F ES Sitecore

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.

Lost User

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 :cool:

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 :suss: 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.

PIEBALDconsult

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.

F ES Sitecore

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.

Jon McKee

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);
//Versus
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.

PIEBALDconsult

Sure, but y approaches 0 . Otherwise, you're saying that you prefer to have buggy code run faster than bug-free code.

Jon McKee

Something not being in a collection isn't by definition a bug. It might be in your case. If y should approach 0 with your collection then exceptions would be the way to go. This has more to do with the data your collection services and the qualities of that data. If you have a unique set for your domain, then the collection will probably rarely run into an access outside of that domain. If the domain is generic then accesses outside of the registered or active parts of the domain will probably be much more common.