First, let's see a few examples of what can go wrong.

Uninitialized variables

int status; pinMode(13, OUTPUT); digitalWrite(13, status); 

Although the variable status is not explicitly initialized by the code above, the C++ compiler does that for you. It sets it as zero. So, even though it's not explicit in the code, we know that the led won't be lit. However, it's not considered good practice to rely on that behaviour. Try and assign values to your variables as it makes the code clearer.

Memory overflow

int array[10]; int v = array[100]; array[-100] = 10; 

The first problem here is that you don't know what will be assigned to v, but worse is that you don't know what you messed up with the assignment to position -100 of array. The good news is that you only messed up with RAM and not with the Flash memory, thus your program is safe.

Jump to an illegal instruction

void doSomething( void ) { for (int i = 0; i < 1000; i++); } void setup () { void (*funcPtr)( void ); funcPtr = &doSomething; funcPtr(); // calls doSomething(); funcPtr = NULL; funcPtr(); // undefined behavior } 

The first call to funcPtr() will actually be a call to doSomething(). Calls like the second one may lead to undefined behavior. In this case, it will continue execution from memory address 0, which seems to be the start of the sketch (I just tested and that's equivalent to a soft boot - it doesn't even go through the bootloader).

Other bad things that may happen

Well, you can run out of RAM, for example. What else. In any case, I think your program will keep running, probably not the way you intended it to.

Kinds of Protection

In computer systems, problems like these are usually dealt with at various levels:

1. By the compiler
2. By the programming language runtime (as in Java for example).
3. By the operating system or the processor (if your memory access a position outside the boundaries of the address space reserved to your program, the OS or the processor may have safety mechanisms to prevent that)

Arduinos only have limited protection of the compiler, and probably nothing else. The good news is that they aren't multi-tasked, so the only program being affected is yours. In any case, any of those bugs will lead to erratic behavior.

The Answers

The assumptions are the all of the problems I stated above are runtime problems.

What happens if there is a runtime error in a program?

The program will continue and what happens will depend on the side-effects of the runtime error. A call to the null function pointer will probably make the program jump to an unknown location.

Will execution of the program just stop?

No, it will keep going as if nothing extraordinary happened, probably doing what you didn't intend it to do. It may reset or act erratically. It may turn some inputs into outputs and burn a sensor or two (but that's highly unlikely).

Is there some way I get the Arduino to tell me what the error is?

I don't think so. As I said earlier, the protection mechanisms aren't there. There's no runtime support from the language, no OS, no hardware checks for out-of-bounds memory access (the bootloader doesn't count as either). You just have to be careful with your program and probably set your own safety nets.

The reason for the lack of protection is probably because Arduino controllers are too cheap, have too little memory, and should not run anything too important (yes, there seems to be a disclaimer by AVR somewhere for you not to use the MCUs normally used by Arduino in life support systems).