1

我正在使用包 drakma，它可以正确执行：

(drakma:http-request "http://www.google.de")

单独使用时。但是，一旦我开始使用自己编写的包，就会导致控制堆栈溢出。回溯看起来像这样：

...htmlstuff.....
200
((:DATE . "Sat, 08 Dec 2012 01:00:23 GMT") (:EXPIRES . "-1")
 (:CACHE-CONTROL . "private, max-age=0")
 (:CONTENT-TYPE . "text/html; charset=ISO-8859-1")
 (:SET-COOKIE
  . "PREF=ID=5c4b30f4308d3e16:FF=0:TM=1354928423:LM=1354928423:S=1Z5pCWaGYqp7vYxW; expires=Mon, 08-Dec-2014 01:00:23 GMT; path=/; domain=.google.de,NID=66=QXQcXBWPNkcLtxxp5Hmlb7enfDS_wlNOA5bfxT-GsokTpAH4fulI8zxOIl_3IQQzeIcIodmcWDc0JC80k7-d-kOPznrhCJYACNu-zpp7wpPXypilOyjK2mebDUnUl3Xj; expires=Sun, 09-Jun-2013 01:00:23 GMT; path=/; domain=.google.de; HttpOnly")
 (:P3P
  . "CP=\"This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info.\"")
 (:SERVER . "gws") (:X-XSS-PROTECTION . "1; mode=block")
 (:X-FRAME-OPTIONS . "SAMEORIGIN") (:CONNECTION . "close"))
#<PURI:URI http://www.google.de/>
INFO: Control stack guard page unprotected
Control stack guard page temporarily disabled: proceed with caution

debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread
#<THREAD "main thread" RUNNING {1002978CA3}>:
  Control stack exhausted (no more space for function call frames).
This is probably due to heavily nested or infinitely recursive function
calls, or a tail call that SBCL cannot or has not optimized away.

PROCEED WITH CAUTION.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR)
0] 



....way more of those....
15854: ((SB-PCL::FAST-METHOD PRINT-OBJECT (T T))
        #<unavailable argument>
        #<unavailable argument>
#1#        #1=
        #<unavailable argument>)
15855: ((LABELS SB-IMPL::HANDLE-IT :IN SB-KERNEL:OUTPUT-OBJECT)
        #<SYNONYM-STREAM :SYMBOL SB-SYS:*TTY* {10001B3103}>)
15856: ((SB-PCL::FAST-METHOD PRINT-OBJECT (T T))
        #<unavailable argument>
        #<unavailable argument>
#1#        #1=
        #<unavailable argument>)
15857: ((LABELS SB-IMPL::HANDLE-IT :IN SB-KERNEL:OUTPUT-OBJECT)
        #<SYNONYM-STREAM :SYMBOL SB-SYS:*TTY* {10001B3103}>)
15858: ((SB-PCL::FAST-METHOD PRINT-OBJECT (T T))
        #<unavailable argument>
        #<unavailable argument>
#1#        #1=
        #<unavailable argument>)
15859: ((LABELS SB-IMPL::HANDLE-IT :IN SB-KERNEL:OUTPUT-OBJECT)
        #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDOUT* {10001DCB03}>)
15860: #1#(PRIN1 #1= NIL)
15861: (SB-IMPL::REPL-FUN NIL)
15862: ((LAMBDA () :IN SB-IMPL::TOPLEVEL-REPL))
15863: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX
        #<CLOSURE (LAMBDA # :IN SB-IMPL::TOPLEVEL-REPL) {10076F355B}>)
15864: (SB-IMPL::TOPLEVEL-REPL NIL)
15865: (SB-IMPL::TOPLEVEL-INIT)
15866: ((FLET #:WITHOUT-INTERRUPTS-BODY-236911 :IN SAVE-LISP-AND-DIE))
15867: ((LABELS SB-IMPL::RESTART-LISP :IN SAVE-LISP-AND-DIE))

大约有 15k 个打印对象互相调用。

我发现错误出现在这三行中：

(define-condition recepie-action-errornous (simple-error) ())

(defmethod print-object (err recepie-action-errornous)
  (rstyl:LOG-ERROR err))

whereas(rstyl:LOG-ERROR err)是一个扩展为：

(WRITE ERR :ESCAPE NIL :STREAM A-PACKAGE:*LOG-STREAM-ERROR*)

价值*LOG-STREAM-ERROR*在于：#<SYNONYM-STREAM :SYMBOL SB-SYS:*TTY* {10001B3103}> 这条线怎么会有这么大的效果？

4

1 回答 1

1

实际上，事情很少。

simple-error是一种定义打印它的特殊插槽的条件，:format-controland :format-arguments. 不幸的是，它们的实用性很小，因为您既不能在子条件的定义中也不能在任何初始化后挂钩中覆盖它们，因为没有。一般来说，我发现simple-error它的用处非常有限，因为它不能只捕获需要打印的消息，而是每次创建此条件的实例时都必须提供消息。

因此，如果您想扩展simple-error，您可以执行以下操作：

(define-condition recepie-action-errornous (simple-error) ()
  (:report
   (lambda (condition stream)
     (declare (ignore condition))
     (format stream "Erroneous recepie action happened"))))

然后，您的日志记录可能如下所示：

(write (make-condition 'recepie-action-errornous) :escape nil)

它会打印"Erroneous recepie action happened"消息。还不错，但是您没有使用将该条件与其祖先条件区分开来的唯一功能condition，即打印格式化输出的能力。

换句话说，我并没有真正看到你的情况在扩展simple-error我看到它的主要功能是根据你在构建它时提供的参数来促进报告，但如果你不提供任何东西，那么它就是一个有点浪费。

于 2012-12-08T13:46:40.513 回答