Re: if Construction fails
Seungbeom Kim wrote:
The word "separate" doesn't seem to have been a good choice.
Consider this case:
class sockaddr_in
{
uint16_t sin_port;
uint32_t sin_addr;
public:
// takes a string in the form "192.0.34.166:80"
sockaddr_in(const char*);
// validator necessary?
static bool valid(const char*);
};
I don't see how this case is so much different. Or maybe I'm not seeing
your point yet.
The problem is: should the constructor of sockaddr_in throw if it
encounters an invalid string, or should the checking be left to a
separate function and an invalid string cause undefined behaviour?
In general, I would always attempt to prevent the possibility of
undefined behaviour. In the above mentioned case, you have a couple of
choices.
1) You can either let you client perform the validation, and the
constructor accept the parameters as correct. This relies on client
code to be correct, is non-encapsulating and if not done, has the
possibility of undefined behaviour, at worst breaking totally unrelated
code. Not an option to choose. Therefore...
2) The constructor is forced to at least perform validation to prevent
undefined behaviour. As you've (or someone) mentioned before the
possibility of performing validation twice is an option.
3) The last choice, which is the one I'm emphasizing, easily covers
your example (or I'm missing something). If it does not, I will, if
writing a constructor at least have validation in the constructor as I
don't want to rely on the client code (not defensive). Going back to
your example, I would once again perform early validation on an per
argument basis. The classes encapsulating the arguments are not written
by the client, and promises exactly what is required from the argument
e.g:
struct SockAddrIn
{
SockAddrIn( const char* ipStr )
: sin_addr_( cstrToSinAddr( ipStr ) )
{
}
uint32_t getSinAddr() const
{ return sin_addr_; }
// Note:
// Throws std::invalid_argument if not a null
// terminated ip address...
static uint32_t cstrToSinAddr( const char* ip )
{ /*implementation*/ }
private:
uint32_t sin_addr_;
};
struct SockPortIn
{
//Similar implementation, validating the parameter
// on construction.
};
//For lack of having a better name...
class IpSocket
{
public:
IpSocket( SockAddrIn addr, SockPortIn port )
{
//No validation required for arguments...
}
};
//Client code...
void foo()
{
//IP address etc. can be read from some external source, but for
// example sake...
const char ip[] = "194.22.11.45"
const unsigned port( 5000 );
IpSocket sock( "194.22.11.45", 5000 );
//...
}
If a function can accept any valid sockaddr_in object as an argument,
that's fine; no further checking is necessary. But no matter in which
class the checking is done, it has to exist somewhere,
Yes, no doubt - and this cannot be expected from the client.
and the problem
is between constructor's exception and another checking function's
return value.
I don't exactly follow what you mean. Each out of range argument can
cause one exception. If any one of them cause a failure, the eventual
constructor will not event be called. The eventual constructor can
literally not fail as result of invalid arguments, as all the failures
that could have happened are handled by non-client code prior to actual
construction. I still agree with handling errors earlier is better than
late (mentioned by James).
And while I see a point in your approach, I don't think that a function
never has to reject the arguments because each of them is valid per se;
there could be correlated constraints. It is certainly possible that
some additional checking should be done even if each of the arguments
has been validated.
I see your point. I'm not sure I see how this is relevent in your
example, though. Was it your intention that the constructor performed
actual connection, and that it could fail due to an invalid host? This
goes further for me than normal checking. If the client attempted to
validate that, he might has well have skipped using the class and
written the code himself. But maybe I'm missing your point (I'm trying,
though:-).
Kind regards,
Werner
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]