|
Was this taken from old .NET 1/1.1 code though? TryParse wasn't introduced until .NET 2.
|
|
|
|
|
It was made with .Net Framework 4.0, So TryParse was definately avaible. I didn't even had to change the target framework specification in the VS Setup.... 
|
|
|
|
|
Which is why I wrote my own utility method, TryParseInt, back in 2001...
The method was based on the primary school teaching "4321" = 1 + 2*10 + 3*100 + 4*1000. An ad-hoc attempt to recreate it (although it's kinda pointless now)
static public bool TryParseInt(string s, out int n)
{
int baseValue = 1;
n = 0;
try
{
for (int pos = s.Length; pos >= 0; pos--)
{
char c = s[pos];
if (c == '-')
{
if (pos == 0)
n *= -1;
else
return false;
}
else if (c <= '0' || c >= '9')
return false;
n += baseValue * (int)(c - '0');
}
}
catch (OverflowException)
{
return false;
}
return true;
}
Funnily enough, when int.Parse was introduced with FW 2.0, I tested a little for fun, expecting the FW method to far and away outperform my simplistic method. But instead it didn't perform nearly as well as my simplistic method.
Of course mine didn't bother about cultures or thousand separators, knew nothing about number formats, only worked for "invariant" (i.e. US!) culture, and even fell back on a try-catch to handle overflow. Still, for our use - where we'd interpret a string as one thing if it was a valid int, otherwise as soemthing else - this worked very well. 
|
|
|
|
|
How did he get it to compile?
A local variable named 'channelnumber' cannot be declared in this scope because it would give a different meaning to 'channelnumber', which is already used in a 'parent or current' scope to denote something else
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Yes, This was a writing mistake by myself. The scond variables name should be "id". Sorry for that.
|
|
|
|
|
Marco Bertschi wrote: The scond variables name should be "id".
That was the first thing I saw, the second was the code didn't do anything. Third, I learned something. I had no idea Parse was slower than TryParse and I wouldn't have found out about it because the user is either a devious B or an idiot and won't put a number where asked to do so, so I wouldn't use Parse a second later than when I found out about TryParse. I also thought that a parsing routine should be as fast for both. Then I thought, it wouldn't be that fast if Parse was hitting exceptions, it gets caught miles from where it blew up and takes a while to get back to doing its job. Was it slow because it was blowing up or is there some intrinsic problem with the routine? (Besides being willing to blow up at the drop of a "h" at.)
"Doh", I shouldn't type while thinking has gone out the window. Forget everything above, I probably have forgotten it already.
|
|
|
|
|
KP Lee
It does something, but I removed the specific code under the Parsing part.
It was not slow because it threw an exception. It was slow because it threw about 500 exceptions during the import of one single file.
However, your are right when you say that only a complete moron of a user would put a string instead of a number when a number is required.
To complete the explanation, I added the whole source code to the original post.
|
|
|
|
|
Parse is not significantly slower than TryParse. (I suspect if you have a look with Reflector, you'll find it uses TryParse under the hood. Academically speaking I suppose it must in that case be slower, but in practice the difference would be insignificant at best.)
But Parse in conjunction with try-catch is obviously a LOT slower than TryParse in conjunction with "if". And it's not necessary for the stack to be deep for this to be the case. Throwing an exception means allocating a new object (the exception) on the heap and this alone makes it far more costly. If you experiment a little with a simple console or winforms app you'll note that the first time you throw and catch an exception incurs a noticeable delay. After that it is a lot faster, but still thousands of times slower than returning a bool.
|
|
|
|
|
He didn't know about TryParse. I don't think that's a crime, really, particularly if not much of that 4 years' experience was in recent .Net. What he's done is exactly the pattern that you had to use before, and still have to use in Java.
|
|
|
|
|
Dear Bob
A good argument indeed. I edited my original post with more information because there came up the whole discussion with performance and "How user-friendly is the program" for us.
And the program used to crahs because it hung up in the whole try-catch story, so at least then he should've been looking for a faster way, doesn't he 
|
|
|
|
|
Well if he's expecting a conversion/parsing exception, he still shouldn't be doing that Pokemon thing
Swallowing exceptions can be very dangerous sometimes, especially with large codebases and large input files.
'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
|
|
|
|
|
True in principle ... but in reality there's no other exception that's going to be thrown in there, so catching Exception instead of FormatException doesn't really offend me in this case.
|
|
|
|
|
OutOfMemoryException and ThreadAbortException come to mind...
Again, it's a big, long process (OP mentioned 50 seconds).
'I'm French! Why do you think I've got this outrrrrageous accent?' Monty Python and the Holy Grail
|
|
|
|
|
I'd say "it depends". If the code was performance-critical, he could have written his own rudimentary method to avoid relying on exceptions to find out if a string represents a valid integer or not. He *should* know that throw-catch is slow, even if he's never seen a TryParse method before.
|
|
|
|
|
I'd add logging of the original string if TryParse returns false.
Maybe it's indicative of a problem with callers if they pass a non-parseable string (somebody sends in "eight" instead of "8"), where you can continue without problems, but you want to research the application and see who's passing the offending strings.
|
|
|
|
|
Maybe you are right, but the input is a machine-generated log file of a medical instrument, so there is no chance for a user to input wrong data. Further, it is possible that a line of the log file contains no ID, so it isn't very useful to search for any descriptions of the ID (which the program does when a Id was found)...
I am not french.
|
|
|
|
|
Hmm.. i see such silly mistakes being done all the time by fellow colleagues. This is due to the fact that, folks think they are good at their code and langauge grip. Inact, they should know that the art of programming has to be tinkered every day, then only such mistakes can be avoided. But hey, its the big EGO :x
|
|
|
|
|
While debugging some problems in an automated console application I ran into this:
try {
} catch(Exception e) {}
I had lost some 15 minutes tracking this problem (product information not updated in the DB and error log came up empty), and you can imagine I got really angry seeing this stuff. I take it seriously to logging errors, even non-fatal ones.
While I can sometimes understand catching Exception, why the hell didn't the guy at least log it?
And then...I had a flash of inspiration. So I did the most devious thing I could think of at the time. Knowing that the colleague that wrote this code rarely uses the debugger (he usually debugs the code by placing Console.Outs, builds the application and runs it), I changed that class and the try-catch into the following (comments are mine, and not present in the code):
class TheClass {
private string GetType() {
return "ISyncService";
}
private int methodThatThrewError() {
try {
} catch(Exception e) {
Helper.logException(this.GetType().ToString(), "RunSyncProcedure", "No error message available", "");
return successCode;
}
return successCode;
}
}
Basically, when this exception occurs, it will appear that it happened in a whole different class (and an interface for that matter).
That should teach them to log stuff properly, or use the debugger.
Yes, I'm a devious SOB, but hey, if they don't care, why should I?
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
That's just evil. And I like it. +5!
I think computer viruses should count as life. I think it says something about human nature that the only form of life we have created so far is purely destructive. We've created life in our own image.
Stephen Hawking
|
|
|
|
|
Why don't you speak to this colleague ?
Until today, to speak is the best way to explain your point, and to be understood.
You might even learn something doing so ...
To play more stupid than the stupid is a sure way to failure, for both you and him.
gzo
|
|
|
|
|
I did, and nothing changed. Although this colleague is a friend, and one of my best actually, he did nothing on this despite my repeated requests.
Patrice STOESSEL wrote: To play more stupid than the stupid is a sure way to failure, for both you and him.
I'm not sure whether to take this as offensive or not.
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
Take as a advice.
your line of thinking is among the lines of:
"oh, they started a war and destroyed themselves, we will teach them a lesson by starting another war!"
makes sense to you?
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
Sentenryu wrote: "oh, they started a war and destroyed themselves, we will teach them a lesson by starting another war!"
makes sense to you?
TBH, actually it does, but I may just have a sick mind  . As I said to Patrice, I repeatedly asked for errors to be logged properly, with no result, so this one was somewhat of a last resort, and half-jokingly made.
I'm the one working on the code 80% of the time and writing 80% of it, and I don't want to have to track errors that are hidden.
I may just be a code Nazi, but I've had to work on legacy projects that had no documentation/code formatting/error handling at all, and it's not pleasant.
I try my best to write readable and understandable code, for me as well for those that will come later (as is exactly the case, tomorrow is my last day at the job), and I only ask the same for my colleagues. I can understand when it's not possible for various reasons, but when it does become a habit I take it seriously.
There is also the argument that I could take it to management, but I didn't want to do that, as I've known this chap for quite a while (went to college together, and then we've become work mates too for the last couple of years) and he's quite a nice guy. My gesture was not made with bad or harmful intentions, but more like a tongue-in-cheek of what can happen when you don't properly trace your stuff.
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
I wonder how long it will be before your replacement posts this code in "code horrors"...
Seriously, if your intention is to "make a point" then it might have been more appropriate to log it with a type of "HowTheHellWouldIKnow" and a message of "So There IS a point to logging after all" rather than deliberately misleading the next poor guy who has to unravel this. If anything, writing incorrect data to the log is just going to make him even LESS likely to log errors, because the log won't be reliable.
I understand your frustration (believe me, I understand!) but I'm not convinced that this was the wisest approach. In the worst case, if there's a serious bug and it takes 5 times as long to debug as it should because of the misleading stuff in the log, your company may lose revenue / customers / credibility and ALL your ex-colleagues may suffer. Suggest you email your pal a note pointing out what you've done... 
|
|
|
|
|
DerekTP123 wrote: Suggest you email your pal a note pointing out what you've done...
No, I think I'll tell him directly.
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
