LISP: Errors In Lisp

  • 1,070 views
Uploaded on

LISP: Errors In Lisp

LISP: Errors In Lisp

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,070
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Errors in Lisp
  • 2. overview
    General error-signaling functions
    Specialized error signaling Forms and Macros
    Special 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 functions
    These 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 args
    The function signals a fatal error. It is impossible to continue from this kind of error.
    • Warn format-string &rest args
    Warn 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 args
    Cerror is used to signal continuable errors, it allows the program to be continued from debugger after resolving the error.
    break &optional format-string &rest args
    Break 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 Macros
    These 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 Analysis
    etypecase 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 tutorials
    Pick 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