0

I have following code:

IEnumerable<Example> examples = someCollection.Where(x => x.IsExample);
object result = examples.SingleOrDefault() ?? (object)DBNull.Value;
return result;

My intention is to use a conditional breakpoint for line 2 to stop execution, if the condition examples.Count() != 1 is met.

Visual Studo returns an error message saying The condition for a breakpoint failed to execute.[...] The error returned was 'The expression cannot be evaluated. [...]'

However, when I added the line var count = examples.Count() and changed the condition of my breakpoint to count != 1 it worked fine.

Is this some kind of bug or is there a reasonable explanation for this error?

Erik T.
  • 370
  • 4
  • 15
  • 1
    As a side issue - I **strongly** suggest returning `null` rather than `DBNull`. `DBNull` is terrible for type safety. – mjwills Jan 13 '20 at 12:10
  • `examples.Count()` is a Linq statement which is being applied to an `IEnumerable`, that would cause the previous line to be executed multiple times, I wouldn't recommend that. – DavidG Jan 13 '20 at 12:11
  • 1
    Does https://stackoverflow.com/questions/42855604/visual-studio-2015-using-linq-in-conditional-breakpoint help? – mjwills Jan 13 '20 at 12:11
  • 3
    The reasonable explanation is that executing LINQ is expensive (e.g. may involve a database request), and the debugger is likely reluctant to do so. Using `var count = ` sidesteps the issue - now the expense is still there but it is expensive in terms of **your program** (which is fine, the debugger doesn't need to be worried about your code being slow - since you wrote it as part of the program) rather than the debugger (in which case the VS team will be blamed for the slowness). – mjwills Jan 13 '20 at 12:14
  • 2
    Also, have you considered instead putting a breakpoint on the *last* line of code that checks whether `result` is equal to `DBNull.Value`? That will be *way* faster (and work!), since it means the LINQ will be executed just once (as part of prorgram execution) and the conditional breakpoint won't need any LINQ check at all. – mjwills Jan 13 '20 at 12:22
  • @mjwills Thank you for your comments. This seems legit. – Erik T. Jan 13 '20 at 12:35
  • 1
    Awesome. Again, I'd strongly recommend moving away from `DBNull`. You will save yourself much heartache. – mjwills Jan 13 '20 at 12:36
  • @mjwills a better explanation as to *why not use DBNull* in this case would be `null` means the absence of a reference to an object and `DBNull` represents an uninitialized variant or nonexistent database column. @@Erik T. [See](https://learn.microsoft.com/en-us/dotnet/api/system.dbnull?view=netframework-4.8) this to learn more. – Trevor Jan 13 '20 at 12:56
  • I'd suggest type safety is a better argument @Çöđěxěŕ - but sure, that is a good reason too. – mjwills Jan 13 '20 at 12:57
  • Strange debugger quirk, it is for some reason fretting over the thread's ManagedThreadId property. Let's call it a bug, the current debugging engine has rather a lot of them. The old one works well, use Tools > Option > Debugging > General, tick "Use Managed Debugging Mode". That selects the debugging engine last used in VS2010, it is much more stable. – Hans Passant Jan 13 '20 at 13:06

0 Answers0