Keep going mode for require-package
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
add a comment |
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
add a comment |
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
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
package error-handling
asked Apr 14 at 16:05
Peregring-lkPeregring-lk
1735
1735
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You can wrap that in
ignore-errors, to ignore any error evaluating it might raise:
(ignore-errors (require-package 'clips-mode))
If you want to ignore only particular errors then you can instead wrap it with
condition-case:
condition-caseis a special form inC source code.
(condition-case VAR BODYFORM &rest HANDLERS)
Regain control when an error is signaled.
Executes
BODYFORMand returns its value if no error happens.
Each element ofHANDLERSlooks like(CONDITION-NAME BODY...)
where theBODYis made of Lisp expressions.
A handler is applicable to an error
ifCONDITION-NAMEis 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 namedebugis present in this list, it allows another
condition in the list to run the debugger ifdebug-on-errorand 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’sBODY...
withVARbound to(ERROR-SYMBOL . SIGNAL-DATA)from the error.
(IfVARisnil, the handler can’t access that information.)
Then the value of the lastBODYform is returned from thecondition-case
expression.
See also the function
signalfor more info.
Why not try to find out what error is raised and why? Set
debug-on-errortotbefore thatrequire-packagegets invoked (without using anyignore-errorsorcondition-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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
You can wrap that in
ignore-errors, to ignore any error evaluating it might raise:
(ignore-errors (require-package 'clips-mode))
If you want to ignore only particular errors then you can instead wrap it with
condition-case:
condition-caseis a special form inC source code.
(condition-case VAR BODYFORM &rest HANDLERS)
Regain control when an error is signaled.
Executes
BODYFORMand returns its value if no error happens.
Each element ofHANDLERSlooks like(CONDITION-NAME BODY...)
where theBODYis made of Lisp expressions.
A handler is applicable to an error
ifCONDITION-NAMEis 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 namedebugis present in this list, it allows another
condition in the list to run the debugger ifdebug-on-errorand 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’sBODY...
withVARbound to(ERROR-SYMBOL . SIGNAL-DATA)from the error.
(IfVARisnil, the handler can’t access that information.)
Then the value of the lastBODYform is returned from thecondition-case
expression.
See also the function
signalfor more info.
Why not try to find out what error is raised and why? Set
debug-on-errortotbefore thatrequire-packagegets invoked (without using anyignore-errorsorcondition-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.
add a comment |
You can wrap that in
ignore-errors, to ignore any error evaluating it might raise:
(ignore-errors (require-package 'clips-mode))
If you want to ignore only particular errors then you can instead wrap it with
condition-case:
condition-caseis a special form inC source code.
(condition-case VAR BODYFORM &rest HANDLERS)
Regain control when an error is signaled.
Executes
BODYFORMand returns its value if no error happens.
Each element ofHANDLERSlooks like(CONDITION-NAME BODY...)
where theBODYis made of Lisp expressions.
A handler is applicable to an error
ifCONDITION-NAMEis 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 namedebugis present in this list, it allows another
condition in the list to run the debugger ifdebug-on-errorand 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’sBODY...
withVARbound to(ERROR-SYMBOL . SIGNAL-DATA)from the error.
(IfVARisnil, the handler can’t access that information.)
Then the value of the lastBODYform is returned from thecondition-case
expression.
See also the function
signalfor more info.
Why not try to find out what error is raised and why? Set
debug-on-errortotbefore thatrequire-packagegets invoked (without using anyignore-errorsorcondition-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.
add a comment |
You can wrap that in
ignore-errors, to ignore any error evaluating it might raise:
(ignore-errors (require-package 'clips-mode))
If you want to ignore only particular errors then you can instead wrap it with
condition-case:
condition-caseis a special form inC source code.
(condition-case VAR BODYFORM &rest HANDLERS)
Regain control when an error is signaled.
Executes
BODYFORMand returns its value if no error happens.
Each element ofHANDLERSlooks like(CONDITION-NAME BODY...)
where theBODYis made of Lisp expressions.
A handler is applicable to an error
ifCONDITION-NAMEis 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 namedebugis present in this list, it allows another
condition in the list to run the debugger ifdebug-on-errorand 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’sBODY...
withVARbound to(ERROR-SYMBOL . SIGNAL-DATA)from the error.
(IfVARisnil, the handler can’t access that information.)
Then the value of the lastBODYform is returned from thecondition-case
expression.
See also the function
signalfor more info.
Why not try to find out what error is raised and why? Set
debug-on-errortotbefore thatrequire-packagegets invoked (without using anyignore-errorsorcondition-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.
You can wrap that in
ignore-errors, to ignore any error evaluating it might raise:
(ignore-errors (require-package 'clips-mode))
If you want to ignore only particular errors then you can instead wrap it with
condition-case:
condition-caseis a special form inC source code.
(condition-case VAR BODYFORM &rest HANDLERS)
Regain control when an error is signaled.
Executes
BODYFORMand returns its value if no error happens.
Each element ofHANDLERSlooks like(CONDITION-NAME BODY...)
where theBODYis made of Lisp expressions.
A handler is applicable to an error
ifCONDITION-NAMEis 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 namedebugis present in this list, it allows another
condition in the list to run the debugger ifdebug-on-errorand 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’sBODY...
withVARbound to(ERROR-SYMBOL . SIGNAL-DATA)from the error.
(IfVARisnil, the handler can’t access that information.)
Then the value of the lastBODYform is returned from thecondition-case
expression.
See also the function
signalfor more info.
Why not try to find out what error is raised and why? Set
debug-on-errortotbefore thatrequire-packagegets invoked (without using anyignore-errorsorcondition-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.
answered Apr 14 at 17:29
DrewDrew
49.3k463108
49.3k463108
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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