<div dir="ltr"><div dir="ltr">Andres,</div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 5, 2019 at 1:15 AM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm more familiar with how a message such as #receive would be implemented in some socket class, than how applications tend to write code that uses that functionality. So, suppose you had a method like this: doTheHttpThing | data | self prepareToDoTheHttpThing. data := [self socket receive] on: SocketError do: [:ex | ^nil]. data preprocess filter blah blah. ^data </blockquote><div> </div><div>Many times, you're not dealing with a single http request, but a series of interrelated requests that represent a conversation. This is somewhat subjective in terms of how one answers the question 'when does it make sense to break this out into it's own method?' but I often end up with something like:</div><div> </div><div>doTheHttpThing</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> So now the problem that the on:do: is dealing with is what happens when the socket disconnects from under the client code. Then #receive fails, there is no recourse, and the answer should be nil. One could do the wrap around like this: data := [self socket receive] on: SocketError do: [:ex | nil]. data isNil ifTrue: [^nil]. and I'd be tempted to write it that way now because who knows that ^nil does today. But suppose that no, that one would rather not have extra statements. Then one might want something like [:ex | ex methodReturn: nil] instead. In this case, why couldn't that be written like this? | data | ^[ self prepareToDoTheHttpThing. data := self socket receive. data preprocess filter blah blah. data ] on: SocketError do: [:ex | nil] Now there's no non-local return as far as exceptions are concerned, and by the way the code is faster in all cases because non-local return is expensive. Once I wrote a multi-process web spider, and I remember writing the code so that the actual networking interaction happened in a very small place that could be controlled easily with patterns such as the above. Is the problem that application code doesn't always factor that nicely to allow that implementation strategy? I do not have enough of a sample to tell. > For example, I have a periodic task which involves ~10k http requests. > A couple hundred of those will fail each run for various reasons: > network errors, server down, server errors, page errors etc. There are > exception handlers at different levels of connection/request handling > that decide if the error is something that needs to be specifically > handled / retried or if terminating the request (or perhaps it was > terminated on us) and returning some specific value to the sender is the > appropriate result. These are almost always non-local returns since > we're failing right in the middle of processing a request which is no > longer valid. I suspect this is one of those cases where the code just doesn't factor nicely, right? > 3) FFI code and dealing with the 'outside world' more generally. > Similar situation as 2: something fails either in an expected place or > in an expected way. The current method can't continue but the sender > can. Examples: a non-critical log file or database can't be found or > has a problem... (maybe) log something to transcript and return from the > method in question. A backup file can't be copied to a secondary backup > location... we probably aren't connected to the network so ignore it and > try again the next time we get called. I have several of these: fatal > to the current method but the sender doesn't care. > > The thing all of these examples have in common is that they are all > essentially resumable, fatal exceptions... that need to resume somewhere > else. Maybe more like critical exceptions that are not fatal simply because of the context in which they occur. You know, it just occurred to me that having such exceptions implement a #defaultAction method isn't really useful, either. Suppose you could arrange the code so that the non-fatal yet critical exceptions were modeled by a particular class. Instead of a million exception handlers everywhere doing something like [...] on: NonFatalIOError do: [:ex | ex methodReturn: nil] one would like #defaultAction to do that. However, #defaultAction cannot do that now because a non-local return in the #defaultAction method of the exception does not do what is required. If exceptions implemented #methodReturn: instead, then it might be possible for #defaultAction to be written like this: NonFatalIOError>>defaultAction self methodReturn: nil This is not perfect yet, and one still needs to mark the return point with on:do:, but maybe there's a way to write even less code here. > Yeah, I can see this in general. I'd even phrase it as "from a best > practices standpoint, we recommend avoiding non-local returns in > exception handler blocks, but if you choose to do that then using the > #methodReturn: method provided for that effect helps the maintainers of > the exception framework keep things working as intended because said > method *defines* what it means to do a non-local return in this > context". > > I'm fine with that. Awesome, this is in the spirit of my initial comments above. > But let's wait until we get there, and especially after we get a feel > for the most difficult cleanup cases. There's no need to put that down > in stone right now. > > C'mon folks, the train is at the station and I'm on board. Let's get > moving... ;-) :)... let's just finish getting the evidence, then we can write the commentary in the right place with full confidence. > I've already started in my code as you've sold me on it being something > to avoid when not needed. I've been holding off going beyond that as I > don't think we've reached agreement as to the best course of action > yet. I'm not convinced that the system code is beyond cleaning up... I'll take a look and see what. Andres. -- Cuis-dev mailing list <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div></div>