libera/#sbcl - IRC Chatlog
Search
13:12:38
easye
Krystof: thanks for the clarification. Will pass it on to "my" MacPorts community as it seems there is still some amount of PPC/Darwin SBCL users, so they can evaluate.
13:56:28
Krystof
having it in our sources is not without cost, even with a specialist maintainer. Ask if the existing ppc/darwin sbcl users in that community is really large enough to justify the effort...
23:37:07
dbotton
what would be the best way to tell sbcl that on an error to not go debugger but also not exit either, so that the app continues to run?
23:40:19
|3b|
restart-case, restart-bind, ignore-errors, etc (not the last one though in most cases)
23:43:54
dbotton
that is not always possible as the errors don't seem to make it to my code, ie they happen in hutchentoot
23:44:41
dbotton
what I am looking for (if exists) a command line method to say print an error, don't go in to the debugger, and don't exit sbcl
23:45:01
mfiano
Use handler-casse to handle hunchentoot's specific condition in the best way for your application
23:46:04
dbotton
It seems these happen in threads that I can't seem to track down related to using clack
23:46:18
mfiano
(handler-case (progn your-code) (hunchentoot:name-of-condition-type (e) (format t "Some message instead of error")))
23:50:17
|3b|
ACTION isn't sure what sbcl could reasonably do beyond what the spec provides, aside from maybe kill individual threads instead of whole thing, but not sure even that would be all that safe
23:50:31
mfiano
If you are using multiple threads then you might want to look into bt:make-thread's bindings argument, or similar for other abstractions.
23:57:37
dbotton
I currently run live sites in a tmux so that the debugger is running, but that is not ideal in a large site
23:59:10
|3b|
no idea if clack is doing things outside hunchentoot's attempt at that, or if something is breaking what hunchentoot does
23:59:30
|3b|
(not everyone gets things right when printing the backtrace to logs errors for example)
0:04:15
|3b|
ACTION wouldn't expect there to be too many types of threads being created though, so seems like it wouldn't take too many times to find which place isn't handling errors properly and patch/bug-report/whatever it
0:15:34
dbotton
no dice... go figure. the errors are broken pipes when they do occur, mostly in the websockets