Is it my fault?
-
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;
}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.
-
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.
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.
-
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
tryand you'll see anexception.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 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
tryand you'll see anexception.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.
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.
-
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. :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 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.
Eddy Vluggen wrote:
Exceptions aren't expensive,
Yes they are.
-
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 :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.
-
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.
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.
-
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 :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.
-
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?
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 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.
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.
-
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);
//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
iffront-loads the cost while the exception back-loads it. My other post[^] shows some code that testedContainsvs 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). Theif...elsecomes in at a weight of 1 for both branches since the check is required for both. Thetry...catchcomes in at a weight of 0 for no exception and 15 for the exception branch. Now we'll use the variablesxandyto 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:14This ratio shows that for the two methods to be equivalent
xmust occur 14 times as much asy. So for this example, 93.3% or more of the calls must generate no exception or you'd be better off with a 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);
//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
iffront-loads the cost while the exception back-loads it. My other post[^] shows some code that testedContainsvs 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). Theif...elsecomes in at a weight of 1 for both branches since the check is required for both. Thetry...catchcomes in at a weight of 0 for no exception and 15 for the exception branch. Now we'll use the variablesxandyto 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:14This ratio shows that for the two methods to be equivalent
xmust occur 14 times as much asy. So for this example, 93.3% or more of the calls must generate no exception or you'd be better off with a check.Sure, but
y approaches 0. Otherwise, you're saying that you prefer to have buggy code run faster than bug-free code. -
Sure, but
y approaches 0. Otherwise, you're saying that you prefer to have buggy code run faster than bug-free code.Something not being in a collection isn't by definition a bug. It might be in your case. If
yshould 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. -
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
tryand you'll see anexception.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.
Eddy Vluggen wrote:
That must be why File.Open doesn't throw any exceptions if you read a non-existing file :rolleyes:
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. :thumbsup:
-
Eddy Vluggen wrote:
That must be why File.Open doesn't throw any exceptions if you read a non-existing file :rolleyes:
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. :thumbsup:
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 :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.
-
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 :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 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 :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.
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.
-
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 :D But, I can always appreciate a thread were we argue for arguings sake :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.
-
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 :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.
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.Openthrows exceptions yetFile.Existsis 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.