On Saturday, May 16, 2020 at 3:16:18 PM UTC-4, Norman Gray wrote:
> [...]
> The exception is thrown inside the 'output' procedure 
> that's provided as the last argument to the 'response' constructor (I 
> belatedly realise this is probably a bad idea). 
> [...]
> But (a) what should I be doing? And (b) since that exception is caught 
> in this with-handlers clause, what is it that's producing the (default) 
> exception output message?  And (c) should I expect the client just to 
> hang here? 
> I'm guessing that an answer to (a) is 'avoid throwing exceptions inside 
> 'output', but given that that will sometimes happen, is the 
> output-response-body/chunked procedure doing the right thing here?  Am I 
> missing something? 

I think you need to decide when to stream, and when not to stream. In my 
web framework, most requests involve computing the entire response string 
prior to calling (response ...), so if an error is encountered, I can send 
an error response instead of a success response.

Currently, the only time I stream a response is when the client is 
downloading CSV output. In that case, there is little chance of an error 
occurring once the streaming begins. I just briefly reviewed some HTTP 
protocol information, and I couldn't find anything that would allow sending 
a 500 response after the 200 response has already be sent i.e. no way to 
switch from success to error mid-stream.

You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to