Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's one idea of the Lisp condition system: you don't return. The handler gets called on error and the full context is still there. The context includes all bindings, dynamic handlers and all possible restarts. The restarts itself are most often generic: Abort, Continue, Use Value, Store Value, ... There can also be several of those. For example the log error could be restarted by using a Abort error to abort a specific action (say, a compilation of a file) , to abort the whole process (say, a compilation of a whole system).


My favored method: return an error object, which includes all the necessary context. Of course, the library writer must anticipate what information might be necessary, but with condition handling he also has to anticipate, what restarts are necessary.


if you return, you can't continue.

With the condition system you implement restarts as a service to the user. You don't have to provide any one. In a typical Lisp system there will be a default handler.

The more restarts you implement, the more choice the user may gets. The handler can also decide which and how many restarts it wants to expose to the user, if at all.


> My favored method: return an error object

Right, so you've unwound your whole stack and now the original caller has to re-set the initial conditions (hoping all the state was discarded with the stack and none leaked), alter whatever needs to be changed (assuming and hoping there's even a way to get a handle on that) and re-wind the whole stack from scratch.

> Of course, the library writer must anticipate what information might be necessary, but with condition handling he also has to anticipate, what restarts are necessary.

Just as you have to "include all necessary context" in your solution...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: