Thanks for reply! @ijp: Yes, I think return received data within exception is ugly. But I have to do it because my consideration is to return received data when *any* exception happens. So if it's not a common connection error, I have to catch it to return the received data, then re-throw the same exception(and cut the received data). Because other program may expect this exception. But I don't claim that this is the best design. Anyway, just a proposal. @Daniel: I realized that seems make "get-bytevector-n" return the received data rather than read-response-body is better. But I'm afraid that it'll conflict with the definition "get-bytevector-n". Say, we ask for n bytes, but it returned m bytes less than n. So the user maybe get confused with the name "get-bytevector-n".
On Fri, Mar 16, 2012 at 2:48 AM, Daniel Hartwig <mand...@gmail.com> wrote: > On 16 March 2012 02:37, Ian Price <ianpric...@googlemail.com> wrote: > > Daniel Hartwig <mand...@gmail.com> writes: > >> For example, reusing the same bytevector and looping over > >> read-response-body! saving the results to disk each time. This limits > >> the memory use to the size of the bytevector *and* removes the copy > >> operation from your implementation (bonus!). > > If you wanted to do it that way, it'd be better to pass in the port > > directly and cut out the middle man. > > > > Indeed. The procedure shown is similar to one from one of my own > projects which features the write-to-disk internally. > > I guess it pays to keep in mind that it is trivial to rearrange > procedures such as this to suit any particular situation. The OP > appeared--to me--to be very over worked for the task. > > Perhaps such error-tolerance/streaming capabilities can be tied in at > a level closer to get-bytevector-n... > > > Regards >
