Bug Types

Runtime Errors

It's impossible to predict every possible scenario that could befall our applications in the wild. But we need to at least try.

Mike Wolfe

Aug 20, 2021 • 4 min read

This is part 5 of a 7-part series comparing different kinds of software bugs.

What is a Runtime Error?

A runtime error is an error that appears while your application is running (clever name, right?).

Note that in my list of error types, the runtime error is the first type of error that your end users will see. As a reminder, the list below goes in order from easiest and least expensive to fix to hardest and most expensive to fix.

Syntax errors
Compile errors
Misunderstood requirements (before you start writing code)
Automated test errors (i.e., failing tests)
Runtime errors
Misunderstood requirements (after you've written the code)
Logic errors

Types 1 - 4 all appear during (or prior to) development. Error types 5 - 7 all appear after the application has been released to the users.

Causes of Runtime Errors

Some runtime errors can be prevented. They are often the result of leaky abstractions. Many of these kinds of errors can be anticipated and handled with grace. As Donald Rumsfeld would say, these are the known unknowns. We know that we can't be sure a network drive will be available at runtime (a known unknown), so we should take that possibility into account when writing code that intends to save files to such a drive.

Some runtime errors are unavoidable. These could be due to "unknown unknowns." These types of runtime errors are often the result of invalid assumptions. For example, there's a common misconception that leap years occur every four years. That's only partially true. Leap years occur every year that is evenly divisible by four...unless that year is evenly divisible by 100...unless that year is evenly divisible by 400.

I was a fully grown adult human being before I learned the whole story behind leap years.

But, honestly, most runtime errors are a result of our limited capacity as human beings to think logically through a complex scenario. These can include off-by-one errors, missing variable initialization, improper nesting of blocks of code, etc. The best way to avoid these types of runtime errors is via automated testing.

Consequences of Runtime Errors

Unhandled runtime errors will cause a hard crash when Microsoft Access is running in Runtime mode. To avoid this, you either need to provide proper error handling coverage or use vbWatchdog to provide boilerplate-free global error handling.

The other problem is that–unless you have automated error reporting–you'll never know about many of your runtime errors. And before you say, "But I always show a message box!" you should be aware that users don't report errors (unless it's an error that prevents them from getting their work done).

Runtime errors can be particularly expensive to fix when they occur part-way through a data-modifying process (INSERTs, UPDATEs, DELETEs, etc.). When that happens, you can spend waaaaaay more time fixing the data than fixing the code. (That's one reason why related database operations should be wrapped inside a transaction.)