+972 52-548-6969
Do you trust your compiler? Really trust your compiler?
time to read 1 min | 83 words
There is a discussion in the alt.net mailing list right now about how far you can and should trust your compiler. I thinks that this is interesting, because this piece of code of mine is on its way to production:
public Guid Create<T>(T newEntity) { using (CrmService svc = GetCrmService()) { object cheatCompiler = newEntity; Guid guid = svc.Create((BusinessEntity) cheatCompiler); return guid; } }
This is part an implementation of an interface in an assembly that cannot reference BusinessEntity.
I am feeling good with this.
Comments
I can tell you one thing about the .NET 1.1 compiler: do not generate your code from an excel spreadsheet function.
If a function line has roughly 60,000 lines, it will compile, but will yield a stack overflow in execution
Shouldn't you constrain that generic method too? Or would that break the calling assembly?
That would break the assembly that define the interface, that is the problem.
you could use some defensiveness (is/throw argumentexception instead of cast), and I don't see the value of using a generic here. do you mean
Guid Create (BusinessEntity newEntity)
in the interface? then what's wrong with this?
Guid Create (object newEntity)
you might want to consider making the whole interface generic, your class could then just implement IWhatever<BusinessEntity>.
I'm sorry but I consider that bad coding. It's not the compilers fault that you accept runtime exceptions...
If you add a where statement, everything will be fine.
public Guid Create<T>(T newEntity)
{
}
Anato,
Well, this doesn't really work. The interface has to reside in another assembly, and you can't add constraints to such an interface method.
Comment preview