LISP: Errors In Lisp
1 like639 views
This document discusses error handling in Lisp. It describes general error signaling functions like error, warn, cerror, and break. It also covers specialized error signaling forms and macros like check-type and assert that allow inserting error checks into code. Finally, it discusses special forms for exhaustive case analysis like etypecase, ecase, ctypecase, and ccase that signal errors if no clause is selected.
![Specialized error signaling Forms and MacrosThese facilitate the user to insert error checks into the code.Check-type place typespec [string]Check-type signals an error if the contents of place are not of the desired type.The user will be asked for a new value, the check-type will store the new value in place and start over.The place must be a generalized variable reference acceptable to setf.Typespec must be a type specifier. (it is not evaluated.)String must be an English description of the type, starting with an indefinite article ( “a” or “an”). (it is evaluated.)](https://image.slidesharecdn.com/errorsinlisp-100326074311-phpapp02/85/LISP-Errors-In-Lisp-7-320.jpg)
![assert test-form [({place}* ) [string {arg}*]]assert signals an error if the value of the test-form is nil.Continuing from this error allows the user to alter the values of some variables , and assert will start over, evaluating the test form again.assert returns nil.](https://image.slidesharecdn.com/errorsinlisp-100326074311-phpapp02/85/LISP-Errors-In-Lisp-8-320.jpg)
LISP: Errors In Lisp
- 1. Errors in Lisp
- 2. overviewGeneral error-signaling functionsSpecialized error signaling Forms and MacrosSpecial Forms for exhaustive Case Analysis
- 3. List functions may signal an error when given incorrect arguments.Each implementation of common lisp will provide an interactive debugger that prints the error message along with suitable contextual information such as which function detected the error.Conditions subsume and generalize the notation of errors.The conditions system also provides means for handling conditions and for restarting a computation after a condition has been signaled.
- 4. General error-signaling functionsThese functions provide mechanisms for warnings, breaks, continuable errors, and fatal errors.The caller specifies an error message( a string) that may be processed by the error handling mechanism.Error message should not contain a new-line character either at the beginning or at the end.
- 5. error format-string &rest argsThe function signals a fatal error. It is impossible to continue from this kind of error. Warn format-string &rest argsWarn prints an error message but normally doesn’t go into the debugger. ‘This may be controlled by the variable break *break-on-warnings*If the variable *break-on-warnings* is not null, then the function warn behaves like break.
- 6. cerror continue-format-string error-format-string &rest argsCerror is used to signal continuable errors, it allows the program to be continued from debugger after resolving the error. break &optional format-string &rest argsBreak prints the message and goes directly into the debugger, without allowing any possibility of interception by programmed error-handling facilities.
- 7. Specialized error signaling Forms and MacrosThese facilitate the user to insert error checks into the code.Check-type place typespec [string]Check-type signals an error if the contents of place are not of the desired type.The user will be asked for a new value, the check-type will store the new value in place and start over.The place must be a generalized variable reference acceptable to setf.Typespec must be a type specifier. (it is not evaluated.)String must be an English description of the type, starting with an indefinite article ( “a” or “an”). (it is evaluated.)
- 8. assert test-form [({place}* ) [string {arg}*]]assert signals an error if the value of the test-form is nil.Continuing from this error allows the user to alter the values of some variables , and assert will start over, evaluating the test form again.assert returns nil.
- 9. Special Forms for exhaustive Case Analysisetypecase and ecase are similar to typecase and case, but signal a continuable error if no clause is selected.Ctypecase and ccase are similar to typecase and case, but signal a continuable error if no clause is selected.etypecase keyform {(type {form}* )}*This control construct is similar to typecase, but no explicit otherwise or t clause is permitted.
- 10. To supply an application-specific error, the user must use typecase with an otherwise clause containing a call to error. Ctypecase keyplace { (type {form}* )}*The keyplace must be a generalized variable reference acceptable to setf.If n o clause is satisfied, ctypecase signals an error with a message constructed from the clauses.
- 11. ecase keyform {({({key}*) | key} {form}* )}*If no clause is satisfied, ecase signals an error with a message constructed from the clauses.It is not permissible to continue from this error.To supply an error message, the user must use case with an otherwise clause containing a call to error.
- 12. ccase keyplace {({({key}*) | key} {form}* )}*The keyplace must be a generalized vale reference acceptable to setf.Continuing from this error causes ccase to accept a new value from the user, store it into keyplace, and start over, making the clause tests again.Subforms of keyplace may be evaluated multiple times.
- 13. Visit more self help tutorialsPick a tutorial of your choice and browse through it at your own pace.The tutorials section is free, self-guiding and will not involve any additional support.Visit us at www.dataminingtools.net