4 ms·
I don't think anyone's concerned about the executable size. It's annoying, but unless you have a lot of should-be-small executables, it doesn't matter. However
by pw0ncakes 17y ago
I don't think anyone's concerned about the executable size. It's annoying, but unless you have a lot of should-be-small executables, it doesn't matter.
However, exposing the innards of a program on event of an error can be undesirable. CL's behavior of dropping you into the debugger is great when you're writing software that doesn't have to be delivered, or that is entirely open-source, but you can't do closed-source executables that way.
- zachbeane 17y agoCL's default behavior drops you into the debugger. That can be customized in delivered applications to do whatever you want. I sell binary-only command-line CL applications to non-technical users and they don't need to know that Lisp's behind it at all.
- pw0ncakes 17y agoInteresting. How hard is this to do? I don't know much about CL.
- lispm 17y agoWrap something like this around a main startup function for your application: (handler-case (main-user-function) (error (c) (princ "a serious error, I'm quitting") (quit)) (condition (c) (princ "we have a problem") (when (y-or-n-p "abort?") (abort)))) It handles conditions of class ERROR in the first clause and conditions of class condition (all kinds of stuff that one can signal) in the second clause. The variable 'c' would be the condition object. You could inspect it and print more useful help, show dialogs, look for restarts and more.
- lispm 17y agoThat's not CL behavior - that's something an implementation in development mode does. The Common Lisp standard does not specify the presence or absence of a debugger You are free to handle all errors in your application and never drop into a debugger. Common Lisp comes with a 'condition system' that let's you handle errors, recover from errors, show users possible restarts and more.
- zachbeane 17y agoThe precise form of the debugger is not specified, but a debugger is described in the standard in chapter 9 and its behavior is roughly outlined in the description of DEBUGGER-HOOK and INVOKE-DEBUGGER.
- lispm 17y agothat are just code examples how to use the provide interface, not real debuggers and not a description how a debugger should work. 1.4.3 Sections Not Formally Part Of This Standard 'Within the concept sections, subsections whose names begin with the words ``Note'' or ``Notes'' or ``Example'' or ``Examples'' are provided for illustration purposes only, and are not considered part of the standard.'
- zachbeane 17y agoI'm not talking about the examples. The normative parts of the standard do talk about a debugger.
- lispm 17y agoit is not even explained what a debugger is. The glossary has two sentences that uses the word 'might' to describe possible functionality. The documentation of INVOKE-DEBUGGER and the debugger hook just describes how the thing is called. What it is and what it does is not described. Is it a REPL? Does it have any commands? What does it print on entering? How are restarts presented? Are restarts presented? What functionality does it provide? Can I get a backtrace? How? I don't see anything like that described.
- zachbeane 17y agoI agree that it is not specified in detail. I disagree with your assertion that the standard "does not specify the presence or absence of a debugger." A debugger's presence is specified. Its behavior is not.