#Error messages Here I agree with Martin that programs which produce output on both standard output and standard error streams should be judged solely on the basis of standard output. However, if it is not possible to separate the streams via redirection, the program should be considered incorrect.

#Types of errors I define two types of errors: ##1. Recoverable errors These are errors which the program can recover from within the bounds of standard language semantics and continue execution from the point the function was called. The most common form is an exception which may be caught by a try/catch clause. Another is a warning which causes a message to be written to standard error, but never interrupts program flow. ##2. Fatal errors A fatal error cannot be stopped by standard exception handling mechanisms. Often they generate a signal. Catching an error with a signal handler would not an acceptable method of recovering an error. Other instances of errors may not cause a crash, but are still fatal if there is no way to catch them.

#Valid Program Forms

##1. Full Program

A full program should take its input from an external sources such as standard input, command line arguments, or files. It should write the results to standard output.

Programs should be allowed to make either kind of error. They should be judged only on the contents of standard output.

##2. Functions

Functions take their arguments from within a program. Their output might be returned from the function call, written to a memory area provided by the caller, or printed to standard output.

Errors may result at two different times from functions: (I) at definition, or (II) at execution.

##(I) Errors during definition I divide function definitions into three further cases:

###a. Code that defines a named function when compiled This kind of function should not generate any Type I errors, i.e. it should compile successfully. ###b. Code that defines a named function when executed This type of code may generate recoverable errors. ###c. An unnamed expression that evaluates to a function (compiled or executed) The code (if interpreted) should evaluate successfully.

##(II) Errors during execution

During executions, functions should be allowed to make recoverable errors, but not fatal errors. It should be possible for a caller to continue execution after calling the function without measures more extreme than a try/catch block. However, it is normally not possible for a function to exit with an error if it also needs to return a value.

Error messages

Here I agree with Martin that programs which produce output on both standard output and standard error streams should be judged solely on the basis of standard output. However, if it is not possible to separate the streams via redirection, the program should be considered incorrect.

Types of errors

I define two types of errors:

1. Recoverable errors

These are errors which the program can recover from within the bounds of standard language semantics and continue execution from the point the function was called. The most common form is an exception which may be caught by a try/catch clause. Another is a warning which causes a message to be written to standard error, but never interrupts program flow.

2. Fatal errors

A fatal error cannot be stopped by standard exception handling mechanisms. Often they generate a signal. Catching an error with a signal handler would not an acceptable method of recovering an error. Other instances of errors may not cause a crash, but are still fatal if there is no way to catch them.

Valid Program Forms

1. Full Program

A full program should take its input from an external sources such as standard input, command line arguments, or files. It should write the results to standard output.

Programs should be allowed to make either kind of error. They should be judged only on the contents of standard output.

2. Functions

Functions take their arguments from within a program. Their output might be returned from the function call, written to a memory area provided by the caller, or printed to standard output.

Errors may result at two different times from functions: (I) at definition, or (II) at execution.

(I) Errors during definition

I divide function definitions into three further cases:

a. Code that defines a named function when compiled

This kind of function should not generate any Type I errors, i.e. it should compile successfully.

b. Code that defines a named function when executed

This type of code may generate recoverable errors.

c. An unnamed expression that evaluates to a function (compiled or executed)

The code (if interpreted) should evaluate successfully.

(II) Errors during execution

During executions, functions should be allowed to make recoverable errors, but not fatal errors. It should be possible for a caller to continue execution after calling the function without measures more extreme than a try/catch block. However, it is normally not possible for a function to exit with an error if it also needs to return a value.