0

Exception thrown: 'System.IndexOutOfRangeException' in System.Data.dll

This is what I'm getting as output when debugging my WPF application. More than once, but nothing else.

No line numbers, no stacktrace, nor anything else to tell me where this is occurring in my code -- Based on how many of these I get and when they occur, I strongly suspect it is happening inside of an (every 10 second) TimedEvent in call(s) to reader.getOrdinal(fieldName) gone awry.

I'd love to prove/disprove that though.

The application doesn't die there, so this gives me the impression that this is happening inside of a try/catch/finally block...but none of my catch blocks output a message like this. If it were in one of my catch blocks, I'd also expect other output as well, which I don't get. I suppose it could be unrelated to any of my code (hence no stacktrace showing a call back to it), and I just happen to be getting a ringside seat to see something going wrong inside of CLR.

If it matters, these calls are attempts to read data out of ancient MSAccess database. I'd post the code if I thought it would be of any help.

I'm an experienced programmer albeit WPF is not my primary expertise, and I've not encountered an exception that gives such useless debugging information like this. My goal here is to understand what it means when this happens and what I can do about nailing down where.

EDIT:

Found it is happening in a try block. WHY does it generate a message for a caught exception?!?

Code follows.

 if (t != null && t.CurrentBoard != 0) // If Game isn't Over
 {
                    int cb = t.CurrentBoard;
                    int cr = t.CurrentRound;

                    try 
                    {
THIS CALL RIGHT HERE

                        col = reader.GetOrdinal(cb.ToString()); // exception if current board score doesn't exist
                    }

                    catch (IndexOutOfRangeException)
                    {
                        col = -1;
                    }

                    if (col != -1 && !reader.IsDBNull(col) && reader.GetValue(col) != DBNull.Value)
                    {
                            // If a score for the current board has been submitted
JoeHz
  • 2,136
  • 1
  • 18
  • 29
  • `I'd love to prove/disprove that though.` Keep commenting out bits of code until the exception stops. When it stops, the bug was in the last block you commented out. – mjwills Dec 01 '18 at 10:31
  • Also, where is it showing as output? If it is in the `Output window` then you may be able to ignore it. Or is it a real exception that is actually appearing as you debug? – mjwills Dec 01 '18 at 10:31
  • I'm reasonably sure it's in multiple places. I'm not even sure how many calls in this method are generating the message.Re: Output Window only. Do tell -- why ignore? – JoeHz Dec 01 '18 at 10:33
  • 1
    https://stackoverflow.com/questions/4393092/c-sharp-a-first-chance-exception-of-type-system-invalidoperationexception – mjwills Dec 01 '18 at 10:35
  • Okay, tweaking the CLR Exception handling tells me that it's generating it from my try{} block that I'm correctly catching. WTF. Why does it do this at all if I'm catching the exception?! – JoeHz Dec 01 '18 at 10:46
  • It would be awesome if you could show us the relevant code. – mjwills Dec 01 '18 at 10:46
  • Yeah, now I know where it's happening. Done. See the single line try block – JoeHz Dec 01 '18 at 10:50
  • Cool - so yeah, best to ignore it. – mjwills Dec 01 '18 at 10:51
  • I will, but I'd still love to know why it even bothers to generate the message. tx again – JoeHz Dec 01 '18 at 10:53
  • Try catch blocks should be rare in any app. You should use global error handlers which give a stacktrace and close your app down. You should check whether the index is out of range or something is null in code rather try -catch - ignore. – Andy Dec 01 '18 at 11:01
  • 2
    `Try catch blocks should be rare in any app.` I strongly disagree with that assertion @Andy. – mjwills Dec 01 '18 at 11:04
  • As do I. In my case, I'm calling an query that's generating a cross-tab result. Columns I'm looking for may not exist yet. It's expected behavior and needs to be handled as normal. To the best of my knowledge, there's no way to check to see if the column exists without throwing an exception if it doesn't. – JoeHz Dec 01 '18 at 11:20
  • Sure, if an error is sometimes inevitable and you just can't tell until you get it then a try catch is appropriate. That is rare though. If that's a datareader you can obtain a list of the columns and check if it contains the column name you want. – Andy Dec 01 '18 at 13:59
  • Just turn on first chance exceptions and the debugger will stop exactly where the error originally occurred. No need for head scratching :). – SledgeHammer Dec 01 '18 at 19:26
  • Yeah, I did that. And Now I want to know why it even bothers sending the notices to the output window when they are inside of try/catch blocks. – JoeHz Dec 02 '18 at 04:29
  • @Andy I suppose one could do it that way but looping over every field as a check is awfully expensive compared to the try/catch approach. Unanticipated error conditions can happen -- and they need to be handled in a graceful way for the user's benefit. If we were all psychic about what can go wrong, then the try/catch keywords wouldn't have been necessary to have.. – JoeHz Dec 04 '18 at 03:14
  • It's because you don't know what can go wrong that you use global error handling. Since exceptions should be exceptional, you need to shut down. Any try catch should be catching specific errors you can definitely handle and which you know will definitely lead to something broken beyond recovery. Catching errorrs is slow whilst iterating a collection of columns is quite fast. It'll be nanoseconds. And this is on the client anyhow – Andy Dec 04 '18 at 10:55

0 Answers0