none
Settings - first chance exception of type 'System.NullReferenceException' RRS feed

  • Question

  • I'm getting following exception :

    A first chance exception of type 'System.NullReferenceException' occurred in Copy DB.exe

    When using the following code (bold part) :

    private void cboDatabase_SelectedIndexChanged(object sender, EventArgs e)
    {
    string s = ((ComboBox)sender).Text.Substring(((ComboBox)sender).Text.IndexOf("_") + 1);
    int i;
    if (int.TryParse(s.Substring(s.IndexOf("_") + 1, 1), out i))
    {
    s = s.Substring(0, s.IndexOf(
    "_"));
    }
    else
    {
    s = s.Substring(0, s.IndexOf(
    "_", s.IndexOf("_") + 1));
    }
    if (UserSettings.Default != null)
    try
    {
    tbTargetDatabaseName.Text =
    UserSettings.Default.PropertyValues[_s_].PropertyValue.ToString();
    }
    catch (Exception ex)
    {
    Console.WriteLine(ex.Message);
    tbTargetDatabaseName.Text =
    UserSettings.Default.Properties[_s_].DefaultValue.ToString();
    }
    else
    tbTargetDatabaseName.Text = s;
    SelectScripts(((
    ComboBox)sender).Text, ref clbScripts);
    }

    This event is firing when I select another item in my combobox, each time I end up with the Excepion in my console window... Unless I set a breakpoint on the line (which causes the exception) and add "UserSettings.Default.PropertyValues[_s_].PropertyValue" to the watch. Afterwards I can remove the breakpoint and trigger the event (time after time) without any issue.

    Anyone knows what's the reason for this behaviour ?

    ps, I used [_s_] as it became a moon-emoticon when using only s.

    Thursday, June 15, 2006 11:52 AM

All replies

  • first change exception means you have unhandled exception. Instead of just puting one line in try, you can put try at the begining of event handler method, so the whole code will be in try structure.

    Also try to debug, maybe there is some code behind property get method that fails to execute.

    Thursday, June 15, 2006 1:27 PM
  •  boban.s wrote:

    first change exception means you have unhandled exception. Instead of just puting one line in try, you can put try at the begining of event handler method, so the whole code will be in try structure.

    Also try to debug, maybe there is some code behind property get method that fails to execute.

    Thank you for the reply.

    But I hate "try ... catch..." as it's so slow, I always try to handle the exceptions another way, by catching null-values etc. The only reason for the try in this case is the error I was getting.

    I've debugged this thing a couple of times, without finding any issue, as I mentioned before, if I debug too much (by using "add to watch") it is working correctly. I already have a workaround (see below) but I'd really like to know what's the reason for this behaviour.

    I substituted the line in bold with this line :
    tbTargetDatabaseName.Text = UserSettings.Default.GetType().InvokeMember(s, System.Reflection.BindingFlags.GetProperty, null, UserSettings.Default, null).ToString();

    Thursday, June 15, 2006 1:42 PM
  • I had a similiar issue.  It turns out that I was hiding a defect.  Check that the debug mode for you page is set to true.  For example:

     

    <%@ Page Language="vb" AutoEventWireup="false" Inherits="Reporting.StubDisplay" debug="True" trace="False" CodeFile="StubDisplay.aspx.vb" %>

     

    This might reveal the acctual cause of the problem.

     

     

    I hope this helps.

     

    Bryant Cobarrubis

    DocEdge

    www.docedgeinc.com

    Thursday, May 31, 2007 9:44 PM
  • Even though this thread is over two years old, I'll post here because it turns up pretty high when using the search string "A first chance exception of type 'System.NullReferenceException' occurred in"

    In my situation, it took me a while to "Doh!" this one out ...

    1. Navigate to "Debug/Exceptions"
    2. Expand the "Common Language Runtime Exceptions" tree.
    3. Expand the "System" branch.
    4. Scroll down to where "NullReferenceException" is, and check the "throw" checkbox, and uncheck the "user-handled".
    5. Debug your project.

    It turns out, in my case, that the exception was being thrown in a try/catch block and since I did not actually catch that type of exception the debugger output was apparently kind enough to point that out and my code executed without protest.

    So, if your internet search brings you here, then have the debugger throw the exception from the namespace where it's occurring so you can find where in your code to trap the exception.

    Hope this tip helps someone else wrestling this type of problem.
    • Proposed as answer by Guddie Friday, August 21, 2009 10:34 PM
    Monday, August 4, 2008 5:49 PM
  • Hi

    The above worked for me, i had an overflow unhandled exception at runtime, which does'nt point to a location in the code. Simply follow the above and every unhadled exception within the given group will be thrown during the debug process. I found that my overflow error was caused by a rare occurance of when a value was been divided by zero (type double).

    Cheers

    Mark
    Tuesday, February 3, 2009 9:56 PM
  • Paul good peace of coding it solved my problem 
    Friday, September 11, 2009 1:18 PM
  • Yes it enabled me to find the one of the errors.  However in our app, this error is being thrown once every second.  I but trapping for this error is only enabling me to catch the first occurance.
    ERJ MCSD MCDBA
    Thursday, September 17, 2009 8:24 PM
  • Thank you, Paul.  That answer was extremely helpful!  It allowed us to trap our error easily.
    Tuesday, November 24, 2009 7:39 PM
  • Helpful.  Thank-you.  t.
    Thursday, June 9, 2011 6:17 AM
  • god saves you paul. thanks.
    Monday, July 25, 2011 8:16 AM
  • Paul, U DA Man.  You just threw me a life saver there saved me so much time. This with approach with the framework reference code is so nice to debug.
    Wednesday, September 21, 2011 10:21 PM
  • Thanks SO much!

    Exactly like you said; I didn't know the window where you can choose which Exceptions are thrown... This helped me a great deal, now I can just sit back and debug!

    Wednesday, October 12, 2011 1:56 PM
  • You just necroed a thread from 2006. Almost a decade old.

    Please check the date before you reply to something that has been answered for ages.

    Thursday, October 8, 2015 12:52 PM