Greetin's all,
As I sit here jamming with some most excellent Sarah Brightman tunes
whilst coding up the BNetEndpoint class (hi, Philippe!) I find myself
in a bit of a quandary and would like to solicit the input of my fellow
devs on this list.
First, the problem domain: the fickle nature of TCP socket
connection(s) means that said connection can change state at any given
moment without so much as a cursory "so long, and thanks for all the
fish." For example, in the BNetEndpoint class one is allowed to
programatically change any aspect of a live connection which directly
effects most aspects of an instance of BNetEndpoint. Said
behind-the-scenes changes will bubble up into userland with potential
adverse side effects.
Next, the quandary: I tend to code using the "contract programming"
development model as I find it very tolerant to both real-world
failures as well as pathological cases. I interpret the essence of
contract programming is that there is a guarantee in place, to wit:
should "A::method()" fail, the member data of whatever instance of
class A won't be left in an indeterminate state. As I read the BeBook,
in the current incarnation of the BNetEndpoint we basically bail out of
a failed connection, leaving whatever instance of BNetEndpoint in an
indeterminate state -- thus my abhorrant confusion.
I guess that the point of this long-winded obfuscated electronic
dissertation is twofold in that I don't want to break binary
compatiblilty with R5 but at the same time I would like to handle
socket connection failures more gracefully than is implied in the
BeBook -- lookin' for validation to my madness.
Comments?
Thanks for your time.
Cheers, Scott
