handling standard errors

Discussion of Common Lisp
Post Reply
hajovonta
Posts: 17
Joined: Wed Aug 24, 2011 12:42 am

handling standard errors

Post by hajovonta » Sat Dec 12, 2015 1:09 am

I have the following piece of code:

Code: Select all

(defun func1 (param)
  (eval (read-from-string param)))
param is arbitrary. If there is any error, it ends up in debugger. I wanted to avoid this by adding an error handler:

Code: Select all

(defun func2 (param)
  (handler-case
    (eval (read-from-string param))
    (error () "error")))
This works great, but I have no information on the type of the error.
I wondered if there is some way to access properties of the error so I can display something to the caller like "division by zero" or "invalid number of arguments" or something like that. I did some googling but the examples I found are only for creating custom conditions and catching them - but in this case I may have a standard error.

pjstirling
Posts: 166
Joined: Sun Nov 28, 2010 4:21 pm

Re: handling standard errors

Post by pjstirling » Sat Dec 12, 2015 4:57 am

IGNORE-ERRORS returns 2 values (e.g. use MULTIPLE-VALUE-BIND) when a condition is signalled, NIL and the condition object that was raised, you could use that instead.

What's the problem with entering the debugger in this situation, though? It should show the user what kind of error was signalled, and have restarts and such.

hajovonta
Posts: 17
Joined: Wed Aug 24, 2011 12:42 am

Re: handling standard errors

Post by hajovonta » Sun Dec 13, 2015 3:12 am

pjstirling: thanks for the heads-up! The instance that the user interacts is on another machine. I need a way to notify him about the error and give details. Possibly raise a similar error there.

What is your opinion about this one:

Code: Select all

(defun func3 (param)
  (handler-case
    (eval (read-from-string param))
    (error (err1) (type-of err1)))

pjstirling
Posts: 166
Joined: Sun Nov 28, 2010 4:21 pm

Re: handling standard errors

Post by pjstirling » Sun Dec 20, 2015 6:25 pm

I apologise for taking so long to reply to this.

Although it's usually called the Condition system, IMO it's really about Restarts, and the really important thing about restarts is that (unlike exceptions, in other languages) the process of deciding what to do in response to a condition often involves the user. This requires interactivity be available, but restarts don't have a portable interface for handing this interactivity off to some external system (which is required in your case).

You might find some of the SWANK code in SLIME useful to steal, since they (obviously) have this sorted out.

Post Reply