method HELLO: Everybody's favorite program. PRINT "Hello world!" return
Note that the Gilda language is not case sensitive and these examples were formatted using a pretty printer.
> gilda -program hello :Compile the program. gilda: Building hello.g gilda: Run Time: C:/Program Files (x86)/Techneon/gilda_run.lib gilda: hello.g --> obj/hello.o > hello :Run the program. Hello world!
Gilda includes a novel exception handling mechanism to help programmers write more reliable programs. In the Hello program an exception could occur if the standard output stream is broken. The method raises an exception and a last chance exception handler in the run time system attempts to print a message to the standard error stream containing a context string and a descriptive message.
Flush) Could not write to a stream.
Since the standard error and output streams are often used in the same the program would likely raise another exception. In this case the last chance handler in the run time system does not contain an exception handler and just quietly terminates. If instead you want to handle the exception, the simplest way is to add a coarse grain exception handler. The example handler attempts to beep when it catches an exception. Note that the handler method is coded in the same file as the primary method.
method HELLO: An example program with an exception handler. PRINT "Hello world!"; Printing can raise an exception. return catch: Catch any exceptions raised in the method body. WARNING_BELL; Foundation library method to make a jazz noise. return
The library method, WARNING_BELL, needs to be imported; which is done inside a class. Class files declare the usual items like user types, static variables and member methods, but also contains declarations so that Gilda programs know how to build themselves. Importing the Gilda Foundation library declares platform specific methods and common programming utilities.
class Hello: A Class file for the Standard hello example program. import Gilda.Foundation :Access the standard programming library. gilda Hello START :Declare the Hello method as the main entry point. end :Designate the end of a Class file.
Nontrivial programs use classes and are compiled starting with the top level class in the class hierarchy. Keywords can be abbreviated to single letters for convenience. In this case -program is abbreviated as: -p
> gilda -p hello.clg gilda: Building hello.clg gilda: Run Time: C:/Program Files (x86)/Techneon/gilda_run.lib gilda: Foundation: C:/Program Files (x86)/Techneon/foundation/ import: Foundation/gilda.foundation.public.clg :Primary Foundation library import: Foundation/type/key/key.clg :A widely used type import: Foundation/type/type.common.public.clg :A variety of type declarations import: Foundation/type/type.text.public.clg :String manipulation import: Foundation/container/gilda.container.public.clg :Basic container classes import: Foundation/system/os.platform.public.clg :Portable Operating System calls import: Foundation/type/file/file.path.clg :I/O utilities import: Foundation/type/assertion/assertion.clg :Exception handling import: Foundation/system/platform.clg :Environmental globals gilda: hello.g --> obj/hello.o class: Foundation/type/assertion/assertion.clg --> obj/gilda$assertion..o elaborate library: Gilda.Foundation icode: asm/gilda_run$elaborate.i --> obj/gilda_run$elaborate.o asm: asm/gilda_run$catch.s --> obj/gilda_run$catch.o
Output from the compiler lists utilities automatically imported from the Foundation library. Comments were added describing each group of utilities. The library has many additional utilities you can explicitly import.
The last line in the compiler output uses a generated assembler file named gilda_run$catch.s that compiles into an object module containing exception information. The line before that compiles a generated Intermediate Code file named gilda_run$elaborate.i used to elaborate (initialize) the Foundation library when the program starts up.
You can suppress informational output using the -Silent switch; abbreviated as -s. The program is built and the hello.exe program file is created.
> gilda -s -p hello.clg > hello Hello world!
Now when the program runs it will either print, beep, do nothing (when the beeper is disabled), or it could raise some other exception. The latter case could occur when the program is run in a terminal emulator and the WARNING_BELL method is implemented to write a control-G to the console via the standard error stream. In this situation the exception raised in WARNING_BELL is nested in an exception handler.
The run time system detects nested exceptions to avoid run away circular exceptions. If the programmer wants to permit nested exceptions the Retry attribute can be added to the "method catch" line. This is useful when writing handlers that want to retry an operation several times before giving up. When no Retry attribute is coded then a Retry fault exception is raised.
Fault exceptions are raised when a program has run amok and are usually indicative of a bug. The run time system or code generated by the compiler will raise a Fault on an exception. They can also be raised by an Assert command; which is useful when debugging and supports the Contract Programming methodology [Meyer]. Methods can exit normally at a Return command or they can exit by raising an Error exception or a Fault.
Faults are treated distinctly from Error exceptions in Gilda programs. After a Fault a typical strategy is to contain damage and retreat to a higher level or gracefully terminate. The context of a Fault is less reliable due to potential corruption and correspondingly language support for Faults is simpler and more coarse.
Next we edit the hello.g method as shown below. It shows how we could catch the Fault and quietly terminate. We added a Trace command to print details about the assertion. Traces are used to debug programs.
method HELLO: An example program with Error and Fault exception handlers. use Assertion :Access the Assertion variable in the Assertion class. PRINT "Hello world!" return catch fault: Catch any Faults that arise. trace Assertion; Trace the assertion context for a program Fault. return; Quietly exit. catch: Catch any Errors raised in the method body. trace Assertion; Trace the assertion context for a program Error. WARNING_BELL; Standard library method to make a jazz noise. return
In theory we could still run into a problem with this program if it is run when there is no memory left. In this scenario after the program launches it attempts to enter the Hello method, but when it tries to allocate a stack frame it runs out of memory. The run time system detects this and raises a Stack Overflow fault to the last chance handler. It would either print a diagnostic message or failing that quietly terminate. If you wanted to explicitly manage the fault you could write a handler to override the default Last Chance handler.
The key observation is that unanticipated exceptions can occur in seemingly correct code. Gilda`s exception mechanism lets programmers manage both anticipated and unanticipated situations as they see fit. You can implement a simple exception handling strategy with little overhead. A more sophisticated strategy can be added with little impact on the principle business logic.
This example illustrates general concepts for exception handling in Gilda. Error exceptions are managed separately from Faults. Handlers can be incrementally added without perturbing code in the body of the primary method. Contrast this with try-throw-catch; which would implement similar behavior by wrapping the Print statement in a Try clause and embed a handler within it as well [Malayeri]. Gilda lets you write well behaved programs that thoroughly check exceptions without becoming cluttered. You can incrementally add new handlers to existing programs; which is a natural way for programmers to work.
Also notice that exceptions are not named. Named exceptions are not necessary for precise exception handling and when using names they need to be carefully managed. Anonymous exceptions are not only less hassle to code, but also avoid problems with name conflicts and inappropriately overloaded names [Miller].
1. Bertrand Meyer. "Applying Design by Contract". IEEE Computer, pages 40-51, October 1992.
2. Donna Malayeri and Jonathan Aldrich. "Practical Exception Specifications", volume 4119/2006, pages 200-220. Springer Berlin / Heidelberg, October 2006. ISBN 978-3-540-37443-5.
3. Robert Miller and Anand Tripathi. "Issues with Exception Handling in Object-Oriented Systems". In European Conference on Object-Oriented Programming (ECOOP), volume 1241, pages 85-103, September 1997.