User Tools

Site Tools


exceptions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

exceptions [2017/06/29 16:47]
barryfp created
exceptions [2018/02/09 04:00] (current)
barryfp
Line 1: Line 1:
 Dana supports runtime exceptions, but implements them differently to many other languages. In particular, exceptions in Dana are considered as **advisory** to an observer. Exceptions cannot be "​caught"​ or otherwise detected to have happened at runtime, and never result in system termination. Instead, exceptions are inherently contained to the function in which they occur, causing that particular function to abort and return the //default value// of its return type (0 for int, 0.0 for dec, false for bool, //null// for arrays, objects and data types, etc.). Dana supports runtime exceptions, but implements them differently to many other languages. In particular, exceptions in Dana are considered as **advisory** to an observer. Exceptions cannot be "​caught"​ or otherwise detected to have happened at runtime, and never result in system termination. Instead, exceptions are inherently contained to the function in which they occur, causing that particular function to abort and return the //default value// of its return type (0 for int, 0.0 for dec, false for bool, //null// for arrays, objects and data types, etc.).
  
-We adopt this advisory model for three reasons. The first is that, because Dana supports the dynamic loading of code at runtime, having a system in which un-caught exceptions may cause system termination would make for potentially very unstable programs. ​The second is that, because we separate interfaces from implementations,​ it's likely that different implementations of an interface may cause different exceptions to be fired in the case of errors. Instead of needing to annotate functions declared in interfaces with every possible exception type that might need to be caught, we instead treat exceptions as advisory and non-disruptive to program execution. Third, we believe that programs should be inherently robust; allowing general language-level exceptions (such as array index out of bounds) to result in large portions of a program aborting, or exiting entirely, creates inherent fragility requiring extensive defensive programming to be employed for robustness.+We adopt this advisory model for three reasons. The first is that, because Dana supports the dynamic loading of code at runtime, having a system in which un-caught exceptions may cause system termination would make for potentially very unstable programs. ​Second, because we separate interfaces from implementations,​ it's likely that different implementations of an interface may cause different exceptions to be fired in the case of errors. Instead of needing to annotate functions declared in interfaces with every possible exception type that might need to be caught, we instead treat exceptions as advisory and non-disruptive to program execution. Third, we believe that programs should be inherently robust; allowing general language-level exceptions (such as array index out of bounds) to result in large portions of a program aborting, or exiting entirely, creates inherent fragility requiring extensive defensive programming to be employed for robustness.
  
 Exceptions in Dana are thrown as follows: Exceptions in Dana are thrown as follows:
exceptions.txt ยท Last modified: 2018/02/09 04:00 by barryfp