7 ms·
LINQ isn't a magic bullet. collection.Where(s=>s.Transaction.Amount < 100).OrderBy(s=>s.Name).Single(); I'll let you debug the intermittent NullReferenceEx
by bananas 12y ago
LINQ isn't a magic bullet.
collection.Where(s=>s.Transaction.Amount < 100).OrderBy(s=>s.Name).Single();
I'll let you debug the intermittent NullReferenceException that threw in production with no PDBs...
- MartinCron 12y agoBut look at how concise and readable that is!
- Bognar 12y agoYou would get a null reference exception if you unrolled that into a loop, too. You should know what your data is going to look like and if any elements could be null or not. Don't blame LINQ for your lack of null checking.
- bananas 12y agoYep but you'd know which dereference it was if you unrolled it. Nulls happen unfortunately even with the best checking and intents.
- nyrina 12y agoNulls happen, that's why you use the best checking. It's not the best checking if you get thrown NullReferenceExceptions
- bananas 12y agoDefinitely but that gurantee is thrown away the moment you pull a 3rd party black box in. I'm suggesting it's feasible but not necessarily perfect and when it does go boom, which it does when you have 100 million HTTP hits a day, you need to be able to find out precisely where it went wrong. LINQ makes that damn hard: NullReferenceException Company.Product.Assembly.Namespace.Type.Method() +14 ... When line 14 has 22 dereferences then you have no idea why it broke.