-
Notifications
You must be signed in to change notification settings - Fork 127
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Don't wrap the handler body in with-mapped-conditions
with-mapped-conditions behaves differently on different platforms. In particular on SBCL it takes an arbitrary signal, and renames it to something like usocket:unknown-signal. In itself this is usually not bad, because usually there's nothing wrapping process-connection/process-request. But I'm trying to implement #185, basically make Lispworks use the same code path as all other Lisps. BUT, this hits a small issue, because usocket:with-mapped-conditions does some worse things on Lispworks. It takes that arbitrary condition and converts that into an error, which obviously brings down the request in a bad way when it wasn't even an error to begin with. (In my case, the signal was showing up when asdf was signalling system-out-of-date, which shouldn't be an error) I don't know why this with-mapped-condition is here. I can't tell much from the git history. It feels like it shouldn't be here at all. But I decided to take a conservative approach and move the with-mapped-conditions to just other hunchentoot code, and just made sure it's not wrapping handler bodies. This should be the only issue blocking #185, if this is accepted I'll be testing out my change for #185 for a while and then send out a PR.
- Loading branch information
Showing
2 changed files
with
36 additions
and
36 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters