Peter:
I have a tendancy to agree with Erik. Providing handlers for unused interrupts is not a waste of time. I have had multiple instances in past projects where external influences on the processor would make interrupts get triggered unexpectedly. Sometimes a noise problem would trigger the interrupt logic to steer the processor execution flow to the interrupt. Other times some type of ESD upset would cause the values in I/O registers to get changed unexpectedly and cause some disabled interrupt to become enabled.

In both of the above cases a simple handler shell like Erik suggests can make the your embedded system just a little more robust than it would otherwise be.

There is also the consideration that as long as you do repeat projects with the same microcontroller architecture that you really only have to write the set of these interrupt handlers once. Thereafter the inclusion in each project is as simple as a cut and paste. Keep in mind also that the amount of code space bytes used up to support this interrupt support for unused interrupts is rather small. The 30 to 50 bytes it may take to support it is trivial in a controller with 32K or 64K of FLASH. Only in the smallest projects where you are writing in very tight assembly language and the program has become 1150 bytes and there is only 1K byte of code memory does this become an issue. And then surprisingly I have found some types of these very small code space processors where they do not even have any interrupts or the number of vectors is very limited.

Michael Karas