|
I've had to do that in certain circumstances. Use the right tool for the right job.
|
|
|
|
|
Can you elaborate? I find it hard to conceive of a situation where that would be necessary, but am willing to be proved wrong.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
What came to mind was a Windows Service I wrote a few years back that had to perform a number of related, but not dependent, tasks.
An analog that also came to mind was babysitting... the babysitter will have a number of tasks:
0) Check the kid's homework
1) Feed the kid
2) Put the kid to bed
A problem in one task doesn't mean you can't perform the others:
If the kid doesn't do the homework or has errors, you still feed him.
If the kid doesn't eat his vegetables, you still put him to bed.
Just log it and continue. If the problem is bad enough, alert the parents, but don't go running out of the house.
|
|
|
|
|
Food is a reward for doing the homework. I will be a terrible parent.
Greetings - Jacek
|
|
|
|
|
It's not that bad, unless each step depends on the previous step completing successfully, in which case there's no reason to run the rest when you know they will fail.
|
|
|
|
|
Well, I always have an Uncaught Exception Handler. I program mostly in Java and C# and I don't like any hangs or crashes. get an uncaught handler, if at all an exception occurs, (yes... I give heed to LogException too) if is shown as -
"POSSIBLE BUG... Please help us to fix it by sending a brief bug report"...
|
|
|
|
|
I also like the fact that it will always return false . Did you miss this most important feature?
|
|
|
|
|
) good eyes
|
|
|
|
|
Looks like
on error resume next
|
|
|
|
|
One use for such a structure would be to fully log the error without having debuging info in the compiled form.
If that is the case, then the outer try/catch would be the unnecessary one, not the internal ones.
|
|
|
|
|
I was completely flabbergasted by a piece of C# code, until I saw one line near the top (hidden at first in a collapsed block) that read
using var = System.Int32;
Wow, OK. Yes, you can do that, and yes, that makes var (note the colour) behave exactly like int (well like Int32 really - that is, you can't use it as the base type of an enum), and yes, this forum is highlighting it with the wrong colour in the code block.
modified 27-May-13 2:24am.
|
|
|
|
|
Find them.
Then kill them. Horribly. A lesson must be sent out: do not do this.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Can't... resist... it's... like... a... siren...
(yes|no|maybe)*
|
|
|
|
|
A bit dramatic, but generally I agree.
Mislim, dakle jeo sam.
|
|
|
|
|
Precisely my initial reaction. Their head should be mounted on a pike outside the cube farm's walls as a warning to others.
Software Zen: delete this;
|
|
|
|
|
Whisky Tango Foxtrot?!?
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
Awesome!
Can you some other creating stuff?
like. I dunno...
using int = System.String;
?! :P
|
|
|
|
|
No you can't just throw any keyword in there, it has to be a contextual keyword that isn't a keyword in that context.
For example:
using from = System.SByte;
using let = System.Byte;
using orderby = System.Single;
using select = System.String;
|
|
|
|
|
And this also works:
using System;
...
using String = System.Int32;
And:
String s = "str";
String s1 = 5;
|
|
|
|
|
String is not a keyword, so that's not very surprising..
|
|
|
|
|
harold aptroot wrote: String is not a keyword, so that's not very surprising.. Agreed. My first reaction too.
|
|
|
|
|
I kind of had your first responder's reaction to this code, then recalled my irritation with code that used var and forced me to look-up the return type of the function to figure out what the object was. So, my second reaction was YA, someone is forcing the lazy programmer to stop using the lazy var keyword.
I want to kill 'm and sing his/her praises. You could say I'm conflicted.
|
|
|
|
|
If it was the second then they should have linked it to a class called DoNotUseVar or something.
|
|
|
|
|
BobJanova wrote: they should have linked it to a class called DoNotUseVar or something. The casting error would certainly pop out better. Less confusing than the unsuspected error generated by:
byte a = 10;
var b = a;
byte c = b;
|
|
|
|
|
I haven't used var except where essential in almost 10 years.
|
|
|
|