The Difference Between Runtime & Compile Time Errors

The First step before delving into the difference between runtime and compile time errors is the need to establish a few base concepts. Not every language compiles and actually most of the more popular language on the web are not compiled.

What is compiling?

“A compiler is a computer program that transforms source code written in a computer language into another computer language.” (Via Wikipedia).

Compiling in the most abstract terms means taking our human readable code and converting it into something that is easier for a computer to understand (more quickly). The idea behind compiling is converting our code into a language that will be easier for computers to run.

Quick run through compiling history

This depends on many factors; one of them is the target. Historical applications were built in one language for one type of processor until the birth of cross-compiling that enabled developer to develop on one operating system, applications and know their application would run (or at least most of the times by testing it on the OS level).

The birth of languages that took the OS out of the picture such as Java opened up the door to development that didn’t lean on specific operating systems, enabling developers to build applications that could then be compiled into a mediator language. This mediator language would then be read through a run-time mediator. This type of model took the developer one step away from the details of the specific OS, by enabling developers to focus on one ‘runtime’ (in the Java case Java Virtual Machine) and that runtime managed all expectations with the OS/local computer.

With the evolution of the web and the way users consume information through it, the way developers developed applications changed. Many developers and organizations moved a large amount of their development efforts into the web. A large amount of the data to be consumed would run through a browser on the user local computer, the browser turned into the VM that enabled developers to create content would output (most of the time) the same way in many browsers and operating systems. Historically, working directly with browsers was always an art form validating your content is actually running the way you want it to run on various browsers, operating systems, mobile devices, and so forth.

Many organizations (based on the organizations needs) opted to work with Flash as their main development environment. It helped reduce their costs and enabled them to create cutting edge visual work that didn’t depend on user’s browsers but on there exposure to an up to date flash player.

With the birth of html5 and a new set of capabilities the filed of the industry is changing again. It is clear that Flash and HTML5 are going to slowly exchange rolls in the years to come. Some features and capabilities (mainly new capabilities will stay apart of the Flash spectrum) while some of the more traditional operations are going to move back into the browser.

While this article isn’t here to say what will be in the future, as the best way to find out is to sit back and enjoy the dynamics of the developing world we live in. A more in-depth, interesting Article about why I think flash is here to stay and prosper in the years to come(both the runtime player and the AIR platforms that enable cross platform development in desktops,mobile, tablets and much more) is due on my check list.

Note: The samples used in this article are based on ActionScript 3.0.

But I didn’t mean it…

We are all human and as such we make errors. Actually about 60-80% of development time for most developers is re-factoring and error fixing. Errors are a part of our life as developers. Some language Editors (mainly compiled languages) came to the rescue with some ‘rules’ and ‘regulations’ to try and help developers avoid common issues; When they find an issue they are not happy with, they just stop the process of compiling and trigger an error (a compile time error). Now, even if your favorite language does not have Compiling Errors, all applications have Run-Time Errors – some are easier to catch and some are harder.

“The operations performed at compile time usually include syntax analysis, various kinds of semantic analysis and code generation.”

(Via Wikipedia)

When applications are compiled; if at any time during the compilation they stumble on code that they can’t get through (based on the compiler settings) they trigger an error. The compiler will generate an error and stop compiling the application. At this stage the developer needs to return to their code and fix any issue to enable the continuation of compiling. Example:

If we run this application in Fash it would generate a compiler error alerting the developer that he/she did not close the opening bracket. Meanwhile, if we run the same code in JavaScript it would generate a runtime error (as JavaScript does not compile).

So, what is a runtime error? A runtime error occurs if the issue was not captured at compiling time (or if the application does not compile), and while the application was running an unexpected issue happened such as a file not loading. If you are watching the web with a Flash Debugger player you will enjoy the web less, as most sites generate many runtime errors that are not captured.

Here is an example of creating a runtime Error in flash:

In this example we are running code that will never end. This loop has no end point. When the application compiles there are no errors, as from syntax perspective everything is satisfactory but the loop never ends, and as such flash will after 15 seconds of working on this loop terminate the application and throw an Error.

Summary

Working with languages that don’t compile such as JavaScript are much harder for beginner level developers and advanced developers as well, as they put the responsibility of finding these issues on the shoulders of the developers without many rich tools (to date) that help find edge cases. The level of feedback and information you get is more limited as many errors can happen even in runtime while being very hard to find.

If you are in the process of learning a new language such as JavaScript I recommend learning both types of languages at the same time. One that is more strictly written (such as Flash) and one that is more flexible, and demands from you as the developer a better understanding of the hosting environment you are working within(the browser).