I found it difficult to track the flow of behaviors in the ns.Req.Complete section of the HandleRequest function. This style I'm using isn't the one that was being used before, and I apologize for that. If it's unacceptable, then we can rework it to use structured statements instead, but the vast majority of the code is a type of implicit return 1-armed if pattern, so I tried to keep the levels of nesting from getting crazy (the original code had 4+ levels of nesting, with long else branches).
I believe this fixes #6 and fixes #4 , at least in part. It is also to set the stage to address #3 in a clean way.
It also raises a solution for handling #5. We could either choose to always expunge the object at this point in the process, or we could choose to expunge the object on the outside always. I think it's probably cleaner to expunge the object in the same location as its creation, so I would prefer to move the expunge out of the inner HandleRequest function and just use the existing expunge operation on the outside. This depends on my correct understanding of the behavior of how this all works, though.
I've done some rudimentary testing of this code. I'm not sure if there is a clean way to do a more sophisticated test, but these fixes address the issue that I was having with some stalled behavior in my front-end code.
Let me know if you'd prefer this in a different format or style or otherwise find it acceptable or unacceptable for any reason.
I'm going to make a big pull request because I have a number of changes to make instead of just this one. I'll close this one and open a more generic one.
I found it difficult to track the flow of behaviors in the
ns.Req.Complete
section of theHandleRequest
function. This style I'm using isn't the one that was being used before, and I apologize for that. If it's unacceptable, then we can rework it to use structured statements instead, but the vast majority of the code is a type of implicit return 1-armed if pattern, so I tried to keep the levels of nesting from getting crazy (the original code had 4+ levels of nesting, with long else branches).I believe this fixes #6 and fixes #4 , at least in part. It is also to set the stage to address #3 in a clean way.
It also raises a solution for handling #5. We could either choose to always expunge the object at this point in the process, or we could choose to expunge the object on the outside always. I think it's probably cleaner to expunge the object in the same location as its creation, so I would prefer to move the expunge out of the inner
HandleRequest
function and just use the existing expunge operation on the outside. This depends on my correct understanding of the behavior of how this all works, though.I've done some rudimentary testing of this code. I'm not sure if there is a clean way to do a more sophisticated test, but these fixes address the issue that I was having with some stalled behavior in my front-end code.
Let me know if you'd prefer this in a different format or style or otherwise find it acceptable or unacceptable for any reason.