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-case
is a special form inC 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 ofHANDLERS
looks like(CONDITION-NAME BODY...)
where theBODY
is made of Lisp expressions.
A handler is applicable to an error
ifCONDITION-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 namedebug
is present in this list, it allows another
condition in the list to run the debugger ifdebug-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’sBODY...
withVAR
bound to(ERROR-SYMBOL . SIGNAL-DATA)
from the error.
(IfVAR
isnil
, the handler can’t access that information.)
Then the value of the lastBODY
form is returned from thecondition-case
expression.
See also the function
signal
for more info.
Why not try to find out what error is raised and why? Set
debug-on-error
tot
before thatrequire-package
gets invoked (without using anyignore-errors
orcondition-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-case
is a special form inC 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 ofHANDLERS
looks like(CONDITION-NAME BODY...)
where theBODY
is made of Lisp expressions.
A handler is applicable to an error
ifCONDITION-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 namedebug
is present in this list, it allows another
condition in the list to run the debugger ifdebug-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’sBODY...
withVAR
bound to(ERROR-SYMBOL . SIGNAL-DATA)
from the error.
(IfVAR
isnil
, the handler can’t access that information.)
Then the value of the lastBODY
form is returned from thecondition-case
expression.
See also the function
signal
for more info.
Why not try to find out what error is raised and why? Set
debug-on-error
tot
before thatrequire-package
gets invoked (without using anyignore-errors
orcondition-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-case
is a special form inC 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 ofHANDLERS
looks like(CONDITION-NAME BODY...)
where theBODY
is made of Lisp expressions.
A handler is applicable to an error
ifCONDITION-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 namedebug
is present in this list, it allows another
condition in the list to run the debugger ifdebug-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’sBODY...
withVAR
bound to(ERROR-SYMBOL . SIGNAL-DATA)
from the error.
(IfVAR
isnil
, the handler can’t access that information.)
Then the value of the lastBODY
form is returned from thecondition-case
expression.
See also the function
signal
for more info.
Why not try to find out what error is raised and why? Set
debug-on-error
tot
before thatrequire-package
gets invoked (without using anyignore-errors
orcondition-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-case
is a special form inC 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 ofHANDLERS
looks like(CONDITION-NAME BODY...)
where theBODY
is made of Lisp expressions.
A handler is applicable to an error
ifCONDITION-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 namedebug
is present in this list, it allows another
condition in the list to run the debugger ifdebug-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’sBODY...
withVAR
bound to(ERROR-SYMBOL . SIGNAL-DATA)
from the error.
(IfVAR
isnil
, the handler can’t access that information.)
Then the value of the lastBODY
form is returned from thecondition-case
expression.
See also the function
signal
for more info.
Why not try to find out what error is raised and why? Set
debug-on-error
tot
before thatrequire-package
gets invoked (without using anyignore-errors
orcondition-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-case
is a special form inC 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 ofHANDLERS
looks like(CONDITION-NAME BODY...)
where theBODY
is made of Lisp expressions.
A handler is applicable to an error
ifCONDITION-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 namedebug
is present in this list, it allows another
condition in the list to run the debugger ifdebug-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’sBODY...
withVAR
bound to(ERROR-SYMBOL . SIGNAL-DATA)
from the error.
(IfVAR
isnil
, the handler can’t access that information.)
Then the value of the lastBODY
form is returned from thecondition-case
expression.
See also the function
signal
for more info.
Why not try to find out what error is raised and why? Set
debug-on-error
tot
before thatrequire-package
gets invoked (without using anyignore-errors
orcondition-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