Keep going mode for require-package












1















In my initialization file, I have got:



(require-package 'clips-mode)


The thing is that, lately, this package fails to be loaded sometimes (it's already downloaded but I guess it fails when it tries to check for new versions of the package), and when this happens, the initialization file stops reading and subsequent sentences are not read.



I'd like to know if there are a way to ignore errors and keep going even if this specific require-package sentence fails, so the rest of the initialization code is applied anyway.










share|improve this question



























    1















    In my initialization file, I have got:



    (require-package 'clips-mode)


    The thing is that, lately, this package fails to be loaded sometimes (it's already downloaded but I guess it fails when it tries to check for new versions of the package), and when this happens, the initialization file stops reading and subsequent sentences are not read.



    I'd like to know if there are a way to ignore errors and keep going even if this specific require-package sentence fails, so the rest of the initialization code is applied anyway.










    share|improve this question

























      1












      1








      1


      1






      In my initialization file, I have got:



      (require-package 'clips-mode)


      The thing is that, lately, this package fails to be loaded sometimes (it's already downloaded but I guess it fails when it tries to check for new versions of the package), and when this happens, the initialization file stops reading and subsequent sentences are not read.



      I'd like to know if there are a way to ignore errors and keep going even if this specific require-package sentence fails, so the rest of the initialization code is applied anyway.










      share|improve this question














      In my initialization file, I have got:



      (require-package 'clips-mode)


      The thing is that, lately, this package fails to be loaded sometimes (it's already downloaded but I guess it fails when it tries to check for new versions of the package), and when this happens, the initialization file stops reading and subsequent sentences are not read.



      I'd like to know if there are a way to ignore errors and keep going even if this specific require-package sentence fails, so the rest of the initialization code is applied anyway.







      package error-handling






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Apr 14 at 16:05









      Peregring-lkPeregring-lk

      1735




      1735






















          1 Answer
          1






          active

          oldest

          votes


















          3
















          1. You can wrap that in ignore-errors, to ignore any error evaluating it might raise:



            (ignore-errors (require-package 'clips-mode))



          2. If you want to ignore only particular errors then you can instead wrap it with condition-case:




            condition-case is a special form in C source code.



            (condition-case VAR BODYFORM &rest HANDLERS)



            Regain control when an error is signaled.



            Executes BODYFORM and returns its value if no error happens.
            Each element of HANDLERS looks like (CONDITION-NAME BODY...)
            where the BODY is made of Lisp expressions.



            A handler is applicable to an error
            if CONDITION-NAME is one of the error’s condition names.
            If an error happens, the first applicable handler is run.



            The car of a handler may be a list of condition names instead of a
            single condition name; then it handles all of them. If the special
            condition name debug is present in this list, it allows another
            condition in the list to run the debugger if debug-on-error and the
            other usual mechanisms says it should (otherwise, condition-case
            suppresses the debugger).



            When a handler handles an error, control returns to the ‘condition-case’
            and it executes the handler’s BODY...
            with VAR bound to (ERROR-SYMBOL . SIGNAL-DATA) from the error.
            (If VAR is nil, the handler can’t access that information.)
            Then the value of the last BODY form is returned from the condition-case
            expression.



            See also the function signal for more info.




          3. Why not try to find out what error is raised and why? Set debug-on-error to t before that require-package gets invoked (without using any ignore-errors or condition-case), and look at the resulting debugger backtrace. It might be better to take care of the cause of such an error, rather than just ignoring it.







          share|improve this answer
























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "583"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2femacs.stackexchange.com%2fquestions%2f48926%2fkeep-going-mode-for-require-package%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            3
















            1. You can wrap that in ignore-errors, to ignore any error evaluating it might raise:



              (ignore-errors (require-package 'clips-mode))



            2. If you want to ignore only particular errors then you can instead wrap it with condition-case:




              condition-case is a special form in C source code.



              (condition-case VAR BODYFORM &rest HANDLERS)



              Regain control when an error is signaled.



              Executes BODYFORM and returns its value if no error happens.
              Each element of HANDLERS looks like (CONDITION-NAME BODY...)
              where the BODY is made of Lisp expressions.



              A handler is applicable to an error
              if CONDITION-NAME is one of the error’s condition names.
              If an error happens, the first applicable handler is run.



              The car of a handler may be a list of condition names instead of a
              single condition name; then it handles all of them. If the special
              condition name debug is present in this list, it allows another
              condition in the list to run the debugger if debug-on-error and the
              other usual mechanisms says it should (otherwise, condition-case
              suppresses the debugger).



              When a handler handles an error, control returns to the ‘condition-case’
              and it executes the handler’s BODY...
              with VAR bound to (ERROR-SYMBOL . SIGNAL-DATA) from the error.
              (If VAR is nil, the handler can’t access that information.)
              Then the value of the last BODY form is returned from the condition-case
              expression.



              See also the function signal for more info.




            3. Why not try to find out what error is raised and why? Set debug-on-error to t before that require-package gets invoked (without using any ignore-errors or condition-case), and look at the resulting debugger backtrace. It might be better to take care of the cause of such an error, rather than just ignoring it.







            share|improve this answer




























              3
















              1. You can wrap that in ignore-errors, to ignore any error evaluating it might raise:



                (ignore-errors (require-package 'clips-mode))



              2. If you want to ignore only particular errors then you can instead wrap it with condition-case:




                condition-case is a special form in C source code.



                (condition-case VAR BODYFORM &rest HANDLERS)



                Regain control when an error is signaled.



                Executes BODYFORM and returns its value if no error happens.
                Each element of HANDLERS looks like (CONDITION-NAME BODY...)
                where the BODY is made of Lisp expressions.



                A handler is applicable to an error
                if CONDITION-NAME is one of the error’s condition names.
                If an error happens, the first applicable handler is run.



                The car of a handler may be a list of condition names instead of a
                single condition name; then it handles all of them. If the special
                condition name debug is present in this list, it allows another
                condition in the list to run the debugger if debug-on-error and the
                other usual mechanisms says it should (otherwise, condition-case
                suppresses the debugger).



                When a handler handles an error, control returns to the ‘condition-case’
                and it executes the handler’s BODY...
                with VAR bound to (ERROR-SYMBOL . SIGNAL-DATA) from the error.
                (If VAR is nil, the handler can’t access that information.)
                Then the value of the last BODY form is returned from the condition-case
                expression.



                See also the function signal for more info.




              3. Why not try to find out what error is raised and why? Set debug-on-error to t before that require-package gets invoked (without using any ignore-errors or condition-case), and look at the resulting debugger backtrace. It might be better to take care of the cause of such an error, rather than just ignoring it.







              share|improve this answer


























                3












                3








                3









                1. You can wrap that in ignore-errors, to ignore any error evaluating it might raise:



                  (ignore-errors (require-package 'clips-mode))



                2. If you want to ignore only particular errors then you can instead wrap it with condition-case:




                  condition-case is a special form in C source code.



                  (condition-case VAR BODYFORM &rest HANDLERS)



                  Regain control when an error is signaled.



                  Executes BODYFORM and returns its value if no error happens.
                  Each element of HANDLERS looks like (CONDITION-NAME BODY...)
                  where the BODY is made of Lisp expressions.



                  A handler is applicable to an error
                  if CONDITION-NAME is one of the error’s condition names.
                  If an error happens, the first applicable handler is run.



                  The car of a handler may be a list of condition names instead of a
                  single condition name; then it handles all of them. If the special
                  condition name debug is present in this list, it allows another
                  condition in the list to run the debugger if debug-on-error and the
                  other usual mechanisms says it should (otherwise, condition-case
                  suppresses the debugger).



                  When a handler handles an error, control returns to the ‘condition-case’
                  and it executes the handler’s BODY...
                  with VAR bound to (ERROR-SYMBOL . SIGNAL-DATA) from the error.
                  (If VAR is nil, the handler can’t access that information.)
                  Then the value of the last BODY form is returned from the condition-case
                  expression.



                  See also the function signal for more info.




                3. Why not try to find out what error is raised and why? Set debug-on-error to t before that require-package gets invoked (without using any ignore-errors or condition-case), and look at the resulting debugger backtrace. It might be better to take care of the cause of such an error, rather than just ignoring it.







                share|improve this answer















                1. You can wrap that in ignore-errors, to ignore any error evaluating it might raise:



                  (ignore-errors (require-package 'clips-mode))



                2. If you want to ignore only particular errors then you can instead wrap it with condition-case:




                  condition-case is a special form in C source code.



                  (condition-case VAR BODYFORM &rest HANDLERS)



                  Regain control when an error is signaled.



                  Executes BODYFORM and returns its value if no error happens.
                  Each element of HANDLERS looks like (CONDITION-NAME BODY...)
                  where the BODY is made of Lisp expressions.



                  A handler is applicable to an error
                  if CONDITION-NAME is one of the error’s condition names.
                  If an error happens, the first applicable handler is run.



                  The car of a handler may be a list of condition names instead of a
                  single condition name; then it handles all of them. If the special
                  condition name debug is present in this list, it allows another
                  condition in the list to run the debugger if debug-on-error and the
                  other usual mechanisms says it should (otherwise, condition-case
                  suppresses the debugger).



                  When a handler handles an error, control returns to the ‘condition-case’
                  and it executes the handler’s BODY...
                  with VAR bound to (ERROR-SYMBOL . SIGNAL-DATA) from the error.
                  (If VAR is nil, the handler can’t access that information.)
                  Then the value of the last BODY form is returned from the condition-case
                  expression.



                  See also the function signal for more info.




                3. Why not try to find out what error is raised and why? Set debug-on-error to t before that require-package gets invoked (without using any ignore-errors or condition-case), and look at the resulting debugger backtrace. It might be better to take care of the cause of such an error, rather than just ignoring it.








                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Apr 14 at 17:29









                DrewDrew

                49.3k463108




                49.3k463108






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Emacs Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2femacs.stackexchange.com%2fquestions%2f48926%2fkeep-going-mode-for-require-package%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Plaza Victoria

                    Puebla de Zaragoza

                    Musa