|
The code below is part of an eventhandler
Very informative and easy to debug
The worse part is that there are quite a few of these constructions in the application at hand. Shouldn't there be a law against such 'programmers'?
.....
try
{
int startNummer = Convert.ToInt32(dataGrid1[dataGrid1.CurrentRowIndex, 0]);
Hashtable ht = Logica.HaalEquipeIDBijStartnummer(editieID);
equipeID = (int) ht[startNummer];
if (!Logica.IsTijdControleIngevoerd(etappeID))
return;
}
catch
{
return;
}
....
Keep smiling,
Marco
|
|
|
|
|
It is in Dutch. I have no problem reading it, and I don't even speak the language (2 minutes at Babelfish will do it). Get a Dutch programmer to translate it for you. Or does program code always have to be in English?
|
|
|
|
|
Can you explain to me what is meant by the catch in this piece of code?
Regards,
Marco
|
|
|
|
|
Sure. It could do with somewhat more comment lines, but the governing logic is clear:
- do some lookups
- return immediately if something is wrong:
---- some data is not found when looking it up in "Logica"
---- an exception is thrown, for example in the conversion of text to int32 (hence the catch)
- proceed if all assumptions are valid
|
|
|
|
|
Aha! so ignore any exception, just return. That is indeed the way to do it. Silly me, what was i thinking?
Regards,
Marco
|
|
|
|
|
Really, what were you thinking. Will the end user report any mysterious issues before you manage to get a new and better job?
Besides, 'some day' we're going to integrate an error capture and/or logging methodology into this business critical high visibility application which re-engineers our business case to leverage best-practice synergies to pro actively actualize our bottom line but at this point we really don't know what features are required and we're REALLY in a hurry to get something done so for now, we'll just put the blocks in place and fill them in later.
Every application I support in this place is filled with this crap. Every programmer who spews this crap out rapidly is a hero (and soon off to bigger and better jobs)
|
|
|
|
|
JohnnySacks wrote: Besides, 'some day' we're going to integrate an error capture and/or logging methodology into this business critical high visibility application which re-engineers our business case to leverage best-practice synergies to pro actively actualize our bottom line but at this point we really don't know what features are required and we're REALLY in a hurry to get something done so for now, we'll just put the blocks in place and fill them in later.
This sounds so scarily like my manager..no wonder we've decided not to listen to him anymore
|
|
|
|
|
arc_10spd wrote: Or does program code always have to be in English?
If you ever want to start a lobby for making a law that states that all code should be in English, I'll make the buttons
|
|
|
|
|
There are about currently about 4,000 unique languages remaining in the world. English will overrun most of them within the next 100 years at the cost of an extraordinary and fascinating diversity in human culture and history stretching back for over 10,000 years (at least that is what some historical linguists claim they can reconstruct). I for one would find it a tragedy if Dutch were to go as well ("not so much a language as an organised method for clearing one's throat"). However, ErikDD, if you MUST have it in English, here is a guess:
....
try
{
int startNumber = Convert.ToInt32(dataGrid1[dataGrid1.CurrentRowIndex, 0]);
Hashtable ht = Logic.ObtainTeamIDAtStartnumber(editID);
teamID = (int) ht[Startnumber];
if (!Logic.IsTimeControlIntroduced(teamID)
return;
}
catch
{
return;
}
...
|
|
|
|
|
Sorry.
Probably should translate etappe as "stage":
...
if (!Logic.IsTimeControlIntroduced(stageID)
...
not
...
if (!Logic.IsTimeControlIntroduced((editID))
...
|
|
|
|
|
*grins* I happen to be one of the relatively few people who actually speak Dutch (aka a Dutchman) but I do appreciate the effort
As for Dutch disappearing, I wouldn't miss it, but I don't enjoy the prospect. It's just that I also believe in code mobility and reusability.
|
|
|
|
|
That would put a new spin on our local culture here outside Phoenix too; we just had our annual "Lost Dutchman Days" festival.
--| "Every tool is a hammer." |--
|
|
|
|
|
ErikDD wrote: *grins* I happen to be one of the relatively few people who actually speak Dutch (aka a Dutchman) but I do appreciate the effort
ErikDD,
A hidden Dutchman! Very drole. And very hard to tell from your English, of course. I have always thought the Dutch speak the best English in Europe. BTW, how was my Dutch translation of the code? I speak English, French, German and two Australian Aboriginal languages, but alas no Dutch, which, if I could find the time I would try to learn. I also have only a Dutch to German phrase book (relic of a vacation in Amsterdam when I lived in Germany 20 years ago), so it was a bit tricky trying to put together a proper translation, and you don't get any nuances from Babelfish.
Thanks for the sly humour! You definitely made me laugh.
Anthony
|
|
|
|
|
arc_10spd wrote: I have always thought the Dutch speak the best English in Europe
What better than the British? Yeah, you may have a point - have you heard some of our dialects!
|
|
|
|
|
I wouldn't have guessed from your translation that you weren't a Dutch speaker, it was right on the mark
As for the homour..I have my good days
Erik
|
|
|
|
|
Hint: use <pre> when formatting code - much more readable
The .NET Framework does supply some operations to find out whether an operation is possible, rather than throw an exception in case of failure. In the case of the above code, you should use int.TryParse instead of Convert.ToInt32 (.NET 2.0 - in .NET 1.x you have to use Double.TryParse then cast to int ), which will return a bool to indicate whether it could convert it.
Lookups in a Hashtable will also throw an exception if the key isn't found. To avoid this, test for the presence of a key using ContainsKey .
Exceptions are slow. Avoid them where not necessary.
|
|
|
|
|
Exactly my point, a catch block is to handle unexpected exceptions, not for program logic. If the exception is not being handled by the catch block, whats the point in using it?
Thank you for your comment Mike.
Regards,
Marco
|
|
|
|
|
|
<br />
<br />
try<br />
{<br />
FileStream fs = new FileStream(name, FileMode.Open, FileAccess.Read);<br />
using (fs) { fs.Close(); }<br />
}<br />
catch (Exception){continue;}<br />
And these are people I am actually supposed to work with
Ad. Btw the 'user' mentioned here doesn't even exist..this is code running in a Windows NT Service. What the author wants to do (I think ) is see if the user for whom he's retrieving the list of files has read permissions on the file, not the Windows NT User the Service is running under.
|
|
|
|
|
ErikDD wrote: What the author wants to do (I think ) is see if the user for whom he's retrieving the list of files has read permissions on the file, not the Windows NT User the Service is running under.
And your solution would be??
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Ah, I'd have to admit that I have no idea Afaik, this is one of the things that despite the power of the .NET Framework is still either very difficult or misunderstood.
I'd start my search in the FileIOPermission and the WindowsPrincipal/-Identity classes and see where I end up from there. Might be completely wrong though.
In any case the above check checks the Windows NT Service account's access, not the requested user's.
|
|
|
|
|
Clickety[^]
[edit]I forgot: read the discussion, too...
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers! We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP Linkify!|Fold With Us!
|
|
|
|
|
Brilliant! I'll give this to my colleague to break his head over
|
|
|
|
|
I especially loved this snippit of code I encountered while rewriting an app:
<br />
FileInfo fi = new FileInfo(name);<br />
<br />
DateTime dt = fi.LastWriteTime;<br />
<br />
int yr = dt.Year;<br />
if (yr >= 2000)<br />
yr -= 2000;<br />
else<br />
yr -= 1900;<br />
<br />
string year = yr.ToString();<br />
if (yr < 10)<br />
year = year.PadLeft(2, '0');<br />
<br />
<br />
<br />
string date = dt.Day + "/" + dt.Month + "/" + year;<br />
Do I even need to post the alternative??
Me and my colleague (NOT the one who wrote the code. Spent at least 15 minutes laughing about the TODO: comment, too. :p
|
|
|
|
|
I was rewriting an application when I came across the following snippit:
<br />
System.Text.UTF8Encoding encoder8 = new System.Text.UTF8Encoding();<br />
System.Text.Decoder utf8Decode = encoder8.GetDecoder();<br />
byte[] todecode_byte8 = Convert.FromBase64String(_body);<br />
int charCount8 = utf8Decode.GetCharCount(todecode_byte8, 0, todecode_byte8.Length);<br />
char[] decoded_char8 = new char[charCount8];<br />
utf8Decode.GetChars(todecode_byte8, 0, todecode_byte8.Length, decoded_char8, 0);<br />
_body = new String(decoded_char8);<br />
Obviously, the culprit ".NET" programmer responsible kinda missed the alternative solution:
_body = Encoding.UTF8.GetString( Convert.FromBase64String( _body ) );
And I wish this was the only occurrence of this..
|
|
|
|