|
) 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.
|
|
|
|
|
I don't like it except in type declaration plus initialise statements ... there's no point doubling up the type information in
var dict = new Dictionary<String, IList<DataColumn>>(); But of course one of the places you can't use it is in field declarations which is where you want to do that a lot!
It's also a bit ugly writing code that saves a Linq query if you declare the type (IQueryable<T>, right?). It seems to be standard to use var there, although I've been known to put the actual type instead.
|
|
|
|
|
BobJanova wrote:
var dict = new Dictionary<String, IList<DataColumn>>();
var columnNameDict = new Dictionary<String, IList<DataColumn>>();
FTFY
Just to ensure that nobody use your dict to find a way to a cathouse. Or something like that.
BTW. I'd like to have this syntax:
Dictionary<String, IList<DataColumn>> dict = new();
I'd have information on type in a more logical place and could concentrate on parameters passed to a constructor. And still no doubling.
Greetings - Jacek
|
|
|
|
|
Yes fair point with the name there. I'd like a type syntax like that (well maybe not exactly like that, it looks a bit weird, but similar) as well, but since we don't and we do have var, it deputises quite well.
|
|
|
|
|
Looks nice, but violates the (already violated) rule that the type of an expression is determined by its parts, not by the context in which it appears.
Of course that rule is already broken by integer constants.. and null cheats with its "null type" that is implicitly convertible to many types.
So I don't know.
|
|
|
|
|
I don't think that's really a rule any more. What's the type of the lambda x => x + 1 ? You can't tell without looking at the calling context.
|
|
|
|
|
It's still a rule, it just doesn't apply everywhere.
The situation for lambda's is particularly bad[^], but that's no excuse to infect the rest of language with such nonsense.
|
|
|
|
|
BobJanova wrote: But of course one of the places you can't use it is in field declarations which is where you want to do that a lot! Of course you can! Just do what the original poster had found being done to it.
|
|
|
|