Related
I need to loop over a List<dynamic> objects.
The list's objects all have values, but for some reason, I am not able to access any of the dynamic object fields. Below is a screenshot of my debug window:
There you can see the object contains fields (such Alias, Id, Name, etc).
I tried both casting it to a IDictionary<string, object> and ExpandoObject, to no avail. I did not face such a thing before: failing to access existing fields in a dynamic object when they exist.
What is wrong here?
The code is throwing a Microsoft.CSharp.RuntimeBinder.RuntimeBinderException with a message stating {"'object' does not contain a definition for 'Name'"}.
The list was created adding anonymously-typed objects, like this:
return new List<dynamic>(fields.Select(field => new
{
Id = field.Id,
Alias = field.Alias,
Name = field.Name,
Type = field.Type,
Value = field.Value,
SortOrder = field.SortOrder
}));
where fields is an ICollection<Field>, a strongly-typed collection.
The telling part is the exception:
{"'object' does not contain a definition for 'Name'"}.
This indicates that the runtime binder was not actually capable of accessing the type you're passing in dynamic (since dynamic does actually enforce visibility rules).
The most likely cause of this is that you're creating the anonymous type in a different assembly from the one where you're subsequently reading it - since anonymous types are declared internal, the consuming assembly cannot access it, causing the error message above.
Contrast with the usual case of runtime binder exceptions:
'<>f__AnonymousType0< string >' does not contain a definition for 'Name'
EDIT:
A possible solution to the problem is to use the InternalsVisibleToAttribute on the assembly containing the anonymous type. However, this is code smell - just like any other use of InternalsVisibleToAttribute or internal itself.
A better way would be to make sure you don't actually pass anonymous types over assembly boundaries - after all, they shouldn't even be used outside of the method they originated from; the fact that they are is basically an implementation detail of .NET - they didn't have another way to do the same thing. This could change in future versions, making the InternalsVisibleToAttribute solution doubly unreliable.
The way your code is using dynamic suggests that your team has flawed assumptions about how dynamic works and how it's supposed to be used. Note how the actual runtime type of List<dynamic> is actually List<object>. The same goes for arguments of type dynamic (which are again just object, albeit marked with DynamicAttribute). And in fact, that really is what dynamic is - it's a way to handle runtime dynamic dispatch - it's not a property of the type or anything, it's just the way you actually invoke whatever you're trying to invoke. For C#, dynamic allows you to skip most of the compiler checks when working with those dynamic types, and it generates some code to handle the dispatch for you automatically, but all of that only happens inside the method where you actually use the dynamic keyword - if you used List<object>, the end result would be exactly the same.
In your code, there's no reason not to use simple static types. Dynamic typing doesn't really give you any benefits, apart from the effort to code the types themselves. If your co-workers don't like that, well, they should present a better solution - the problem is quite obvious, and it's something you need to deal with.
Much worse, it explicitly hides all context, all the type information. That's not something you want in an API, internal or not! If you want to hide the concrete types being used, why not - but you should still expose an interface instead. I suspect this is the reason why anonymous types can't implement interfaces - it would encourage you to go entirely the wrong way.
I work on developing an external API. I added a method to my public interface :
public void AddMode(TypeA mode);
public void AddMode(TypeB mode); // the new method, TypeB and TypeA are not related at all
It looked good, until one test broke that was passing a null . That made the compiler confused with ambiguous call. I fixed the test with casting the null.
However my question is :
Should I change the name just because of this?
Or should let the client do the cast as I did? (if they pass null for whatever reason)
What is the best in this case while designing APIs ?
Edit :
the call was like this AddMode(null) , not like :
TypeA vl = null;
AddMode(v1); // this doesn't cause a problem
An API should be designed so that it's easy to use correctly and hard to use incorrectly.
Your API is easy to use correctly:
AddMode(new TypeA());
does compile.
It's harder to use incorrectly:
AddMode(null);
does not compile. The user ist forced to do something like
AddMode((TypeA)null);
Which should make him think, whether this is expected usage. So I think your API is OK as it is.
I think that depends on how exceptional null as a value for the respective argument is.
Compare, for example, this ArgumentNullException constructor: It is most frequently called when an internal exception has to be set. Otherwise, this constructor, which excepts the name of the illegal argument, is passed. On odd occasions, the former has to be invoked because a custom message has to be supplied, but no internal exception is supplied (I usually do this when I'm throwing the exception for an array/collection argument that contains null, but is not null itself). So, in this case, I need the explicit cast, and I'd say it is acceptable there.
If your methods really do the same, but null is still a usual value, you might want to add a parameterless overload for the null variant (i.e. the explicit cast is still possible, but users can also call the parameterless overload instead).
If your methods do something somewhat different, and yet something else for null, you can think about disallowing null altogether for the methods you've shown and adding a parameterless overload for the null case.
Update: If null is not acceptable anyway (and will result in an exception), then you should leave the method as it is. Other than for testing purposes, there should never be any whatsoever situation in which a literal null would be passed to the method, as this will invariably yield an exception. Therefore, do not change your overload names in this case.
Is null valid input to this method anyway?
Personally I'd leave it as is as long as both overloads of AddMode related, since you'd expect AddMode(X) and AddMode(Y) to be doing something related to each other.
If they are not related in any way, then maybe a method name change is in order
Well, it depends either null value is acceptable value in your API.
If not just do not accept it, by not supporting it. So even if the consumer will try to use it with null the compiler will break on ambiguity problem.
If your API accepts a null as a possible parameter value, then you have to specify it in the documentation and mention it is necessary to cast it, and write some code samples to show how.
However, if you don not want the user to use null values, you might change TypeA and TypeB as a struct instead of a class, if your class design allow it.
Is it possible to enforce rules or throw an error when using object initializers in C#? I'd like to throw a compiler error or warning if an object is initialized but is missing a certain property.
public class Party
{
public string Name { get; set; }
public string Date { get; set; }
public Location Location { get; set; }
}
public class SignUpForParty
{
public void DoSomething()
{
Party party = new Party()
{
Name = "New Years Party!",
Date = "Dec 31, 1999"
// Show WARNING/ERROR here because no Location given
};
}
}
Essentially, I'm looking for a way to ensure that all objects of type Party are created with valid data for every instance.
Obviously I could do this with overloaded constructors, but in some cases I have a lot of properties and writing constructors to match is messy. I'd like to follow a cleaner C# style.
Obj p = new Obj(1, 2, 3,...n); // too many properties to be pretty
Obviously I could do this with overloaded constructors, but in some cases I have a lot of properties and writing constructors to match is messy. I'd like to follow a cleaner C# style.
Object initializers really shouldn't be considered alternatives to writing a constructor.
You should always include constructors in your types if you have requirements like this. It is a good idea to create a default set of constructors (or use optional arguments on one constructor) which at least provide a guarantee that the object will always be created in a valid, meaningful state.
Object initializers are helpful for optional properties, but shouldn't be relied upon for requirements of your type itself.
You cannot force every property to be initialized with an object initializer.
Even if you could, a consumer of the object could provide default (0, null, ...) values. Depending on your needs, consider validating object state at key times (e.g. before it can be saved to a database).
If you go that route, have a look at the IDataErrorInfo interface.
If your type is not valid when only 2 properties are set then you need to fix your design, not emit an error.
You provide a default constructor, which tells me that I don't have to set anything to use the object after initialization. You provide getters and setters for each property, again, implicitly telling users of your class that it is ok to set on but not the other.
If this is not the case then I suggest you provide a constructor which forces me to supply all three values. Yes, I can still use (null, null, null), but you could check for that and throw an error.
Also, if PropertyA is dependent on PropertyB then either
A) Only one of them should have a setter, or
B) There should be logic in the setter of each to properly initialize the other after the value changes.
This is a design problem, not a language problem. You cannot force the initializer syntax to work differently than how it was spec'd.
Obj p = new Obj(1, 2, 3,...n); // too many properties to be pretty
Code isn't supposed to be 'pretty', it is supposed to work. Even then, a constructor which takes a few arguments is 'ugly'? Huh? Don't buy into the hipster nonsense, write code that works and works well.
The only way I could see this implemented is if there was some event (or equivalent) that was raised when the object initializer was completed. There is currently a Connect request for something to this effect.
Unfortunately, I didn't make the cut for .NET 4.5:
Thank you for your suggestion.
This is a great idea, and has the nice property that it doesn't add to the language surface - it just makes object initializers smarter. In principle that would probably make it a breaking change, but that is something we can look into.
Unfortunately we cannot add any more to the release we are currently building, so I am going to resolve as Won't fix for this release. However, I am capturing the suggestion on our list of features for future discussion.
Thanks again!
Mads Torgersen, C# Language PM
Maybe it'll make it's way into .NET 5+.
What about Code Contracts?. This will assert not only that you assigned a value, but you could also specify valid ranges.
Or for check at runtime with debug builds only, you could use Debug.Assert(...) calls to achieve the same as above.
While designing a class ( in c#, or any oop lang) i always get confused with shall i have property defined in a class and use it in methods of class , or it's good to simply have method parameters.
One problem i found in first way is that it creates dependancy (like , what if caller has forgotten to assign the value to the property etc..).
e.g. I am designing a class "myexcel" which does "export to cvs" , "Get XML" , "format excel and save"
Here shall i have "ExcelPath" as property of myexcel or shall i pass it as parameter to GetXml , export , format methods ?
Properties should define the state associated with object - the state information that qualifies say one instance from other instance. It does not make sense to store a temporal information that is valid for a single function invocation into the object state. In other words, if you make something a object property because its get used in some method then it would only make sense if the same property value is used across multiple invocation or the property get used in multiple methods.
So in your particular case, filePath should be a parameter for all save/export methods because from usage perspective, the object instance represent some data and save/export is a just a way to serialize it. The file path would be valid for that call only - it will likely to change over multiple invocations.
It's a bit of a judgment call. In your example, it depends on whether you want instances of your type to represent specific files in the file system. If so, throw an invalid operation exception when Save is called but Path is invalid. If not, require a path parameter for the Save method, and throw an invalid argument exception if the value is invalid.
More generally, properties should represent state, while method parameters should represent information that's needed by the method, but external to the object's state.
Lets try this small example.
You have a class WashingMachine. Its duty is to wash clothes.
class WashingMachine
{
public void WashClothes()
{
}
}
Now will you make List<clothToWash> listOfCloth a property or parameter to WashClothes?
It will be clear if it is made as parameter to WashClothes rather than Property, because it does not define the state of the object.
In addition to that, Properties should be cheap, should not throw exceptions while assigning values.
Hope that helps.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Casting: (NewType) vs. Object as NewType
In C#, why ever cast reference types when you can use "as"?
Casting can generate exceptions whereas "as" will evaulate to null if the casting fails.
Wouldn't "as" be easier to use with reference types in all cases?
eg:
MyObject as DataGridView
rather than,
(DataGridView)MyObject
Consider the following alternatives:
Foo(someObj as SomeClass);
and:
Foo((SomeClass)someObj);
Due to someObj being of the wrong type, the first version passes null to Foo. Some time later, this results in a NullReferenceException being thrown. How much later? Depends on what Foo does. It might store the null in a field, and then minutes later it's accessed by some code that expects it to be non-null.
But with the second version, you find the problem immediately.
Why make it harder to fix bugs?
Update
The OP asked in a comment: isn't is easier to use as and then check for null in an if statement?
If the null is unexpected and is evidence of a bug in the caller, you could say:
SomeClass c = someObj as SomeClass;
if (c == null)
{
// hmm...
}
What do you do in that if-block? There are two general solutions. One is to throw an exception, so it is the caller's responsibility to deal with their mistake. In which case it is definitely simpler to write:
SomeClass c = (SomeClass)someObj;
It simply saves you writing the if/throw logic by hand.
There is another alternative though. If you have a "stock" implementation of SomeClass that you are happy to use where nothing better is available (maybe it has methods that do nothing, or return "empty" values, etc.) then you could do this:
SomeClass c = (someObj as SomeClass) ?? _stockImpl;
This will ensure that c is never null. But is that really better? What if the caller has a bug; don't you want to help find bugs? By swapping in a default object, you disguise the bug. That sounds like an attractive idea until you waste a week of your life trying to track down a bug.
(In a way this mimics the behaviour of Objective-C, in which any attempt to use a null reference will never throw; it just silently does nothing.)
operator 'as' work with reference types only.
Sometimes, you want the exception to be thrown. Sometimes, you want to try to convert and nulls are OK. As already stated, as will not work with value types.
One definite reason is that the object is, or could be (when writing a generic method, you may not know at coding-time) being cast to a value type, in which case as isn't allowed.
One more dubious reason is that you already know that the object is of the type in question. Just how dubious depends on how you already know that. In the following case:
if(obj is MyType)
DoMyTypeStuff((MyType)obj);
else
DoMoreGeneralStuff(obj);
It's hard to justify using as here, as the only thing it really does is add a redundant check (maybe it'll be optimised away, maybe it won't). At the other extreme, if you are half-way to a trance state with the amount of information you've got in you're brain's paged-in memory and on the basis of that you are pretty sure that the object must be of the type in question, maybe it's better to add in the check.
Another good reason is that the difference between being of the wrong type and being null gets hidden by as. If it's reasonable to be passing in a string to a given method, including a null string, but it's not reasonable to pass in an int, then val as string has just made the incorrect usage look like a completely different correct usage, and you've just made the bug harder to find and potentially more damaging.
Finally, maybe if you don't know the type of the object, the calling code should. If the calling code has called yours incorrectly, they should receive an exception. To either allow the InvalidCastException to pass back, or to catch it and throw an InvalidArgument exception or similar is a reasonable and clear means of doing so.
If, when you write the code to make the cast, you are sure that the cast should work, you should use (DataGridView)MyObject. This way, if the cast fails in the future, your assumption about the type of MyObject will cause an invalid cast exception at the point where you make the cast, instead of a null reference exception at some point later.
If you do want to handle the case where MyObject is not a DataGridView, then use as, and presumably check for it being null before doing anything with it.
tl;dr If your code assumes something, and that assumption is wrong at run-time, the code should throw an exception.
From MSDN (as (C# reference)):
the as operator only performs reference conversions and boxing conversions. The as operator cannot perform other conversions, such as user-defined conversions, which should instead be performed using cast expressions.
Taking into consideration all of the comments, we came across this just the other day and wondered why you would do a direct cast over using the keyword as. What if you want the cast to fail? This is sometimes the desirable effect you want from a cast if you're casting from a null object. You then push the exception up the call stack.
So, if you want something to fail, use a direct cast, if you're okay with it not failing, use the as keyword.
As is faster and doesn't throw exceptions. Therefore it is generally preferred. Reasons to use casts include:
Using as, you can only assign types that are lower in the inheritance tree to ones that are higher. For example:
object o = "abc" as object;
DataGridView d = "abc" as DataGridView // doesn't do anything
DataGridView could create a custom cast that does allow this. Casts are defined on the target type and therefore allow everything, as long as it's defined.
Another problem with as is that it doesn't always work. Consider this method:
IEnumerable<T> GetList<T>(T item)
{
(from ... select) as IEnumerable<T>
}
This code fails because T could also be a Value Type. You can't use as on those because they can never be null. This means you'll have to put a constraint on T, while it is actually unnecesary. If you don't know whether you're going to have a reference type or not, you can never use as.
Of course, you should always check for null when you use the as keyword. Don't assume no exceptions will be thrown just becase the keyword doesn't throw any. Don't put a Try {} Catch(NullReferenceException){} around it, that't unneccesary and bloat. Just assign the value to a variable and check for null before you use it. Never use it inline in a method call.