|
Path.Combine doesn't always work as one would wish
|
|
|
|
|
This leads me to once again point out how important that cup of coffee is before commencing to write any code.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
|
|
|
|
|
commited
|
|
|
|
|
Both the exists checks are unneeded. A manual would be more appropriate.
The FMSDN says:
If the directory already exists, this method does nothing.
|
|
|
|
|
we cant know! we cant judge.its windows afterall 
d'Oh!
|
|
|
|
|
a fellow student told me of a strange code convention in his job:
almost every single method looks like this
{
try {
}
catch (...) {
}
}
directly after the head opens a try block over the whole body. all errors are just thrown away. the programs work and never crash!
they are world market leader
seems this fast and easy developing is quite successfull at all. they are more engineers, so these kludges seem appropriate.
modified on Thursday, July 1, 2010 2:57 PM
|
|
|
|
|
Discarding errors is a great way to give the user the perception that all is right with the world.
|
|
|
|
|
RugbyLeague wrote: Discarding errors is a great way to give the user the perception that all is right with the world.
Old VB6 provided a more convenient means, though: "ON ERROR RESUME NEXT". Unfortunately, its lack of "Try"-style methods for many things(*) tended to make a more appropriate coding style painful.
(*) There are many places where one might want to do an operation which one expects might fail, and not worry if it does; e.g. one may want to create a table if it doesn't exist, but ignore it if it does. Checking for existence before creation won't completely solve the problem, since another client might create the table after the existence check. The nicest way would be to say "do command X, but don't worry if it fails." Unfortunately, the only convenient way to do that is with ON ERROR RESUME NEXT, a concept so ugly Microsoft defined a special statement just for it.
Incidentally, if a routine does an ON ERROR RESUME NEXT and then invokes another routine that fails but does not have an ON ERROR statement, that other routine will exit out to the routine which did the ON ERROR RESUME NEXT. Nasty, but not so horrible as ON ERROR RESUME, which would restart the entire statement in the parent routine, likely causing many statements in the called routine to be re-executed.
|
|
|
|
|
RugbyLeague wrote: a great way to give the user the perception that all is right with the world.
That's the goal, according to some of the teachers here.
If you find yourself in such a group, by all means, adapt or leave - you'll be the source of all bugs and errors if you try to move to structured error-handling
I are Troll 
|
|
|
|
|
Eddy Vluggen wrote: you'll be the source of all bugs and errors if you try to move to structured error-handling Smile
Fair point.
Steve
|
|
|
|
|
Eddy Vluggen wrote: you'll be the source of all bugs and errors if you try to move to structured error-handling
so right^^ once turning on printing error messages to stderr, there was so much outpu - it was turned off immediately 
|
|
|
|
|
Kevin Drzycimski wrote: directly after the head opens a try block over the whole body. all errors are just thrown away.
In Enterprise lingo, that's called the Try/Swallow pattern.
Jon Sagara
Some see the glass as half-empty, some see the glass as half-full. I see the glass as too big.
-- George Carlin
.NET Blog | Personal Blog | Articles
|
|
|
|
|
Jon Sagara wrote: Try/Swallow
I'm scared to reply to that one!
DaveIf this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier.
Please take your VB.NET out of our nice case sensitive forum.(Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
|
|
|
|
|
DaveyM69 wrote: Jon Sagara wrote:
Try/Swallow
I'm scared to reply to that one!
Dave
Promise, it won't swallow you, Dave. 
|
|
|
|
|
So, did they patent this? o_O
|
|
|
|
|
dont know, but I had to laugh so hard when he told me this...
everybody who knows the disciplines of "Software Engineering" must either laugh or puke
|
|
|
|
|
It's from BP's oil valve device driver source code..
|
|
|
|
|
Haha, funny. Sadly enough, I used to swallow exceptions in code as well. However, I'm not in the professional field, just personal. It worries me that this sort of thing is done by professionally employed developers. xD
|
|
|
|
|
|
I think the point was that it was in EVERY method ...
|
|
|
|
|
Apparently you are not a man of faith, and do not realize that this is a Marine software design tactic. Swallow 'em all and let God sort 'em out!
Honestly Illustrated
<Pretentious> Raid tha manyuhl. :E
<Pretentious> Aw raid eh own mah meaxbile. :E
|
|
|
|
|
I'm guessing that the convention dates from the VB style, used to use this:
Function Wibble() As String
Dim sResult As String
On Local Error GoTo Fail
'stuff goes here
done:
Wibble = sResult
Exit Function
Fail:
LogError "Wibble", Err
Resume done
End Function
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
|
|
|
|
|
well, the difference is, that your code logs the error.
in try/swallow it just thrown away.
logging all the error messages might bloat the logfile 
|
|
|
|
|
If you have common functions reachable by the GUI, that are not important for the main of the application, this is a really usefull and stable act, and i do it in almost the same manner for at least the common methods.
For example i wan't to change a image of a specified object. Now my ChangeImage() method throws a unhandled exception, with this try catch block around the method body there will be no quaint exception message, the application won't crash because of a single method exception, only the ChangeImage() method isn't working.
Sorry for my bad english.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
