Re: Throwing error is potentially buggy
wij@seed.net.tw wrote:
On 6???7???, ??????6???16???, Goran <goran.pu...@gmail.com> wrote:
On Jun 4, 3:38 pm, w...@seed.net.tw wrote:
class receive_error : public std::exception { ... };
class send_error : public std::exception { ... };
class processing_error : public std::exception { ... };
initialize();
while (true) {
try {
Message msg,out;
receive(msg);
process(msg,out);
send(out);
}
catch (receive_error& e) {
// receive() barfed
}
catch (processing_error& e) {
// process() barfed
}
catch (send_error& e) {
// send() barfed
}
// other exceptions propagate out
}
For the revised example program to work. Those thrown objects nearly
have to be unique to the extent that no other function can throw the
same error.
No, program will work even if you only throw std::exception, just as
if it will work if you use bool return and e.g. never set errno (or
similar).
Surely throwing std::exception can work (too much complicated to
be practical). Take another String member function for instance:
int String::insert(size_t index, const String& str);
Funny that you bring up a string class as example, which would be utterly
useless without exceptions. Consider a constructor taking a char* or an
overloaded operator+ not throwing when they go out of memory. Basically, it
means that you can not sensibly use them, which severely restricts the
usability of your string class.
Possible error equivalents are EINVAL EFBIG ENOMEM ELOOP(str is self)
Throwing them, one should consider the possibility of being
misinterpreted.
Many would say throwing exceptions is simple and elegant.
Yes it is, but not until the program contains catch codes.
Throwing error is not equivalent to returning error, rather it is
equivalent to a throw (with insignificant object) and an errno
like global variable.
I don't understand where you see the similarity with a global errno variable
from. If you mean that, equally to errno, you can't always be sure where it
came from, then I don't see how that differs from returning an int as
errorcode.
The complete code for the server-like program scenario can be lengthy
if expanded to real compilable form. But I guess my intent should be
made clear by now.
initialize();
while (true) {
Message msg,out;
receive(msg);
process(msg,out);
send(out);
}
In general there are quite some exceptional conditions that are
normally supposed to be handled in the server-like program loop:
Reply by return (or the equivalent):
EINTR signal interrupted
This one is more or less a glitch in the interface of Unix systems. This one
can and should be handled exactly where it happened:
while(true) {
int e = some_sys_call(...)
if(e==0)
return; // success
if(e==EINTR)
continue; // try again
throw system_error("some_sys_call", e);
}
ELOOP too many links or as mentioned above
I don't understand this error type.
> ENOSPC no buffer space
EINVAL this may by dynamic (e.g. format error)
EPIPE peer down
ETIMEDOUT preset timeout
ENAMETOOLONG long pathname
EFBIG too large data, similar to ERANGE
[...]
I don't see any possible catch program can be both simple and
elegant as is usually declared. Note the baseline is correctness.
All these should probably close the connection. Some of these might merit
sending an error response and then optionally closing the connection.
Again, while you provided info about the errors you expect, you omitted how
you intend to handle these errors individually, which is crucial! So I'll
have to guess...
try {
while(true) {
try {
Message in = connection.receive_request();
Message out = process(in);
connection.send_response(out);
} catch(processing_error const& e) {
// handle processing errors by replying with an
// according error code stored in the exception
connection.send_error_response(e.error_id);
}
}
} catch(std::exception const& e) {
connection.close();
}
Uli
--
Sator Laser GmbH
Gesch??ftsf??hrer: Thorsten F??cking, Amtsgericht Hamburg HR B62 932
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]