[virtuald]

Originally Posted by Phazonmutant

So, just to recap:
-START_ROBOT_CLASS, through many convolutions, defines the entry point FRC_UserProgram_StartupLibraryInit, which is called from external code (on the cRIO), which:
-Spawns a new task running an instance of the robot class

Do I have that right?

Yes.

OK, so, in lieu of using try-catch blocks, I should use wpi_assert around conditionals that try to trap errors like null pointers?

No. On code that you run on a 'normal' system, when the condition inside the parentheses of assert() is false, the program immediately prints out a message with whatever is inside the parentheses and a line number and the program ends (strictly speaking, it isn't always implemented this way, but thats typically the case). However, when NDEBUG is defined, then assert expands to nothing and does nothing.

Additionally, if a debugger is attached, when the assert condition is false then the debugger usually takes over at that point and you can examine the local variables and see what happened that caused the condition to be false.

Now why is that useful? When you're making something, its useful to put in little checks basically saying "this condition should never happen, if it does then we need to immediately stop execution". You can also put in more expensive checks in there that only run in the debug build, so that way the code is more optimized in the release build (since, the checks are not done if NDEBUG is defined).

switch (some_val)
{
    case 1:
        // do something
        break;
    case 2:
        // do something
        break;
    default:
        // some_val should never be this
        assert(0 && "this should never have happened");
}

An alternative way of doing this would be:

assert((some_val == 1 || some_val == 2) && "this should never be a different value");

switch (some_val)
{
    // cases here... 
}

However, this usage of assert does not seem to be what is implemented in WPILib by default. In particular, it does not appear to care about the value of NDEBUG. Instead it just prints out the error message and continues (as far as I can see, without actually going back up the stack). However, if you call wpi_suspendOnAssertEnabled(true) then I believe you will get this type of behavior.

Look at Utility.cpp in WPILib for the implementation.