From: Ariel B. <aba...@be...> - 2008-10-01 16:46:58
|
See http://article.gmane.org/gmane.lisp.steel-bank.devel/11314 --- src/code/toplevel.lisp | 26 ++++++++------------------ 1 files changed, 8 insertions(+), 18 deletions(-) diff --git a/src/code/toplevel.lisp b/src/code/toplevel.lisp index 4cc0b0c..9ec1159 100644 --- a/src/code/toplevel.lisp +++ b/src/code/toplevel.lisp @@ -330,32 +330,27 @@ command-line.") (defun process-init-file (specified-pathname default-function) (restart-case (let ((cookie (list))) - (flet ((process-stream (stream &optional pathname) + (flet ((process-stream (stream) (loop (restart-case - (handler-bind - ((error (lambda (e) - (error "Error during processing of ~ - initialization file ~A:~%~% ~A" - (or pathname stream) e)))) - (let ((form (read stream nil cookie))) - (if (eq cookie form) - (return-from process-init-file nil) - (eval form)))) + (let ((form (read stream nil cookie))) + (if (eq cookie form) + (return-from process-init-file nil) + (eval form))) (continue () :report "Ignore and continue processing."))))) (if specified-pathname (with-open-file (stream (parse-native-namestring specified-pathname) :if-does-not-exist nil) (if stream - (process-stream stream (pathname stream)) + (process-stream stream) (error "The specified init file ~S was not found." specified-pathname))) (let ((default (funcall default-function))) (when default (with-open-file (stream (pathname default) :if-does-not-exist nil) (when stream - (process-stream stream (pathname stream))))))))) + (process-stream stream)))))))) (abort () :report "Skip this initialization file."))) @@ -376,12 +371,7 @@ command-line.") (dolist (expr-as-string-or-form eval-strings-or-forms) (/show0 "handling one --eval option") (restart-case - (handler-bind - ((error (lambda (e) - (error "Error during processing of --eval ~ - option ~S:~%~% ~A" - expr-as-string-or-form e)))) - (process-1 expr-as-string-or-form)) + (process-1 expr-as-string-or-form) (continue () :report "Ignore and continue with next --eval option."))) (abort () -- 1.6.0.2.249.g97d7f |
From: Nikodemus S. <nik...@ra...> - 2008-10-06 12:18:55
|
On Wed, Oct 1, 2008 at 7:49 PM, Ariel Badichi <aba...@be...> wrote: > > See http://article.gmane.org/gmane.lisp.steel-bank.devel/11314 >From there: > I use the --load option to run a program which may signal an error. > The program sets up restarts so that I can interactively choose how to > deal with the error, but these are lost when I arrive at the debugger. > > The reason for this is that the function SB-IMPL::PROCESS-EVAL-OPTIONS > tries to be "helpful" by setting up a handler which signals yet > another error. In doing this, the handler does not decline to handle > the condition, and so the restarts established up to that point are no > longer available. This analysis is not entirely correct. The restarts are still there -- however, if those restarts are associated specifically with your original condition, they are no longer applicable. RESTART-CASE magically associates its restarts with the signaled condition in certain cases: "If the restartable-form is a list whose car is any of the symbols signal, error, cerror, or warn (or is a macro form which macroexpands into such a list), then with-condition-restarts is used implicitly to associate the indicated restarts with the condition to be signaled." Contrast and compare the behaviour of (restart-case (progn (error "foo")) (my-restart () (print :OK))) and (restart-case (error "foo") (my-restart () (print :OK))) when placed in foo.lisp, and processed using "sbcl --load foo.lisp". > Another solution is to remove the handler altogether. I prefer this > solution, as I think the restarts established by PROCESS-EVAL-OPTIONS > are sufficiently helpful. > > I also noticed a similarly "helpful" handler in the function > SB-IMPL::PROCESS-INIT-FILE. I am personally fairly attached to the annotations associated with --eval options, since they have on several occasions been real time-savers when figuring out where an error comes from, particularly when dealing with --eval options involving reader magic. However, I do see your point. Losing restarts because of resignaling is annoying to say the least. I've committed a reworking of the patch you posted as 1.0.21.9: * --disable-debugger takes effect before init files are processed. * Don't resignal errors in annotated form: this loses restarts originally established with (RESTART-CASE (ERROR ...) ...). * Make the restarts we provide more explicit about the cause of the error, including the exact commandline option (or initialization file name and kind) in the restart text. Cheers, and thanks for the patch! -- Nikodemus |
From: Ariel B. <aba...@be...> - 2008-10-07 00:50:36
|
"Nikodemus Siivola" <nik...@ra...> writes: > RESTART-CASE magically associates its restarts with the signaled > condition in certain cases: > I wasn't aware of this - thank you for bringing this up. > I am personally fairly attached to the annotations associated with > --eval options, since they have on several occasions been real > time-savers when figuring out where an error comes from, particularly > when dealing with --eval options involving reader magic. > > However, I do see your point. Losing restarts because of resignaling > is annoying to say the least. > > I've committed a reworking of the patch you posted as 1.0.21.9: > Thanks, again. Ariel |