|
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.
|
|
|
|
|
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 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.
|
|
|
|
|
Well, perhaps "bug" was over-stating my opinion a bit, perhaps "poorly-developed" is a better term, and as I stated in my edit -- searching for a parameter by name (and probably members of other collections as well) is a code smell. Best to avoid it. In many cases, the developer will know what's in a collection. This is true of the program I was working on -- I know the parameter is in there, I even know that it's at index 0, so why search for it by name?
BUT, I write a lot of library/framework code that others might use (yeah, as if), so I need to keep "lesser developers" in mind. 
As luck would have it, I was just re-reading a "List of Principles" of Programming Languages and saw this:
"Localized Cost: Users should only pay for what they use; avoid distributed costs." -- MacLennan, 1987
I would apply this to the current discussion as: "Programs which call GetParameter only when the parameter is known to exist should not have to pay for the double-checking that would benefit only other programs."
Is my code still violating that Principle? Yes. Because my GetParameter function tries to be provider-neutral, it has protection against calls that return NULL (e.g. Oracle) -- a program that uses SQL Server will still be paying that cost with no benefit to itself. However, the test for NULL is much less than the double-search.
|
|
|
|
|
I see where you're coming from given that example. I tend to enjoy writing more dev-oriented tools as well.
Abstractions such as labels/names don't bother me though. In my mind there's no difference between representing a key via integer or string if you're free to make the choice; they're both just abstractions in this context. The only requirement for a key is a unique set of bits however that ends up implemented.
I recently watched a great Computerphile[^] video where he was touching on the subject of abstraction using assemblers. Apparently John von Neumann thought assemblers were harmful because they took more processing time. Neumann thought this was wholly unnecessary because you could simply manually address the program making a double-pass by the assembler a waste of time (double because you need to scan for forward-jumping labels first). Got me thinking about the more general debate topic when you have multiple techniques to accomplish effectively the same thing and how advantages/disadvantages can sometimes be relative to the developer or the architecture.
|
|
|
|
|
If you are concerned about finding the maximal intersection of readability, performance and reliability, it is advised to ALWAYS use the bool TryGet( key, out value ) pattern and avoid bool Contains( key ) like the plague.
Moreover, after a TryGet returns false, do not use the Add method since it checks AGAIN for the existence of the item. Instead, use the set indexer to assign the value to the key's index.
if (!items.TryGet( key, out T value ))
{
value = GetNewValueLogic( key );
items[key] = value
}
Extremely readable, and it provides the best possible performance in all cases.
|
|
|
|
|
A good suggestion; but the IDataParameterCollection interface doesn't provide a TryGet method. As far as I can see, none of the concrete implementations do either.
Personally, I think ConcurrentDictionary[^] provides a better API than the standard Dictionary:
T value = items.GetOrAdd(key, GetNewValueLogic);
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Apologies. That's not an API that I was familiar with. I'm shocked that a TryGet isn't provided!
|
|
|
|
|
I had an evil idea so I ran this script on my local SQL server database:
CREATE PROCEDURE TESTPROC
AS BEGIN
SELECT 1
EXEC TESTPROC
END
When I executed the stored procedure, it stopped after 32 levels of nesting. My evil plan failed and I learnt something new today.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
If you change to a recursive CTE you can play around with OPTION (MAXRECURSION 100)
|
|
|
|
|
Each time a stored procedure calls another stored procedure or executes managed code by referencing a common language runtime (CLR) routine, type, or aggregate, the nesting level is incremented. When the maximum of 32 is exceeded, the transaction is terminated.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I will take over the world before you do.
Just letting you know! 
|
|
|
|
|
No it won't, unless it takes over 32 people at a time. 
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
It will take over thousands upon thousands!
And it's only 10 years away around the corner!!!! 
|
|
|
|
|
I saw something similar happen with a trigger making a change that was then running the same trigger again.
The updates were extremely slow and I discovered that there was, like you have discovered, a point at which SQL Server gave up - when the recursion was 32 deep.
You would hope that the SQL Server would just catch this sort of thing at compile time.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I resorted to a GOTO in an SQL query Loop that created a new transaction to work round a repetitive action with an unknown data set size. It was dirty, but worked. Glad I didn't try recursion as that would have definitely ended in tears by the sound of things!
You can read about the problem here.....Developing Automated Data Purge Solution, but it basically looks like this;
LoopStart:
IF (@Count - @RowCountTotal) > @BatchSize
Begin
Begin Transaction
Delete Top (@BatchSize) From Comment Where CommentTime < @StartDate
Set @RowCountTotal = @RowCountTotal + @@RowCount
Commit Transaction
Goto LoopStart
End
Else
If (@Count - @RowCountTotal) > 0
Begin<br />
Begin Transaction
Delete Top (@Count - @RowCountTotal) From Comment Where CommentTime < @StartDate
Set @RowCountTotal = @RowCountTotal + @@RowCount<br />
Commit Transaction
End
|
|
|
|
|
IMO, recursion is inherently dangerous, and must be avoided whenever possible. Moreover, when you must use recursion, you must also take steps to ensure that your recursive routine converges and unwinds its recursive stack. Every recursive routine must incorporate a test that stops the recursion in such a way that the recursion depth is self-limiting.
This is true regardless of the programming language in which the recursion occurs. Whenever I encounter a recursion, my first thought is to investigate other algorithms that don't rely on recursion. More often than not, I have managed to succeed in finding one.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I have conclusive proof of something that I have long suspected; file times for files that fall outside the current DST/Standard time period are reported off by 1 hour by the Windows command prompt (CMD.exe). I'll be publishing the proof later today.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
|
Thanks for the article citation. Nevertheless, since Windows has the transition date tables mentioned in the article, and NTFS stores UTC times on disk, I see no reason that it shouldn't be fixed, even if doing so required a new switch. After all, said switch could be set in the DIRCMD environment variable.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Like the Unix linefeed mode support in Notepad that will be introduced after 30 years with the next Windows 10 version?
That will be enabled by default but can be disabled with a registry key.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
