2.0 Errors and Warnings

If you are wondering why the documentation is beginning by talking about errors, the answer is because error handling during development with CrxOop is likely to be the most confusing part if not understood properly. There are two types of 'errors', Errors and Warnings. Both are reported in the console of your browser, or IDE, and it is possible to have them reported else where if you so wish.

Warnings are non fatal errors. This means that you can likely continue running your application without problems. However, warnings should not be taken lightly, and are very likely to be turned to errors in the future.

Errors are fatal, and the most common are Definition Errors. When errors are encountered an exception is thrown that escapes the entirety of CrxOop without being caught. The exception is thrown for the convenience exceptions provide in unrolling the stack, but not because CrxOop expects you to catch them. Whether you catch those exceptions in your code or not, CrxOop will halt. This is done by setting an internal flag before throwing the exception.

When halted, most exposed functions of CrxOop, as well as class instance functions will stop working. When it comes to Definition Errors, the behavior is equivalent to those fatal errors caused by wrong syntax in other interpreted languages like PHP. PHP would continue running until it loads a PHP file that has a syntax error and then it halts immediately. In our case this happens mostly with definitions, not files. CrxOop will continue running until it encounters a definition with wrong 'syntax' and halts then. Note that class explicit registration, interface explicit registration, and structure explicit registration do not trigger parsing of the definitions and hence even if there are definition errors, that part of the code will continue running happily. Parsing only happens when the definition is actually required, such as a call to crx_new().

Starting with v1.6, CrxOop includes support of including a stack trace for most common errors. The stack trace filters out CrxOop inter function calls, leaving you with clean stack trace. The stack trace works best if either Stacktrace.js or TraceKit is available. If both are included, CrxOop gives precedance to TraceKit.

When developing, always look at your console. The console is likely to point you to the line of code that threw the error, or the definition that caused the error. Starting with v1.6, as well as the CrxOop message, you might see two stack traces on the console, one labeled clearly to be from CrxOop, and this is the one you want. If you do not see this, chances are you have an error in the definition itself, and in this case the clue in the error will be in CrxOop's message, not the other stack trace.

When it comes to definition errors you will not get an actual line of code pointing to the error, but you are likely to get the name of the class or interface with the malformed definition. For this reason, it is recommended that classes, interfaces, and structures be explicitly registered. If they are not, you will get a cryptic name of the class or interface where the error is.