Re: Why do some code bases don't use exceptions?
On 25 Nov, 16:28, legalize+jee...@mail.xmission.com (Richard) wrote:
peter koch <peter.koch.lar...@gmail.com> spake the secret code
<99e979fd-651c-4a27-a72a-d3eab8bd9...@e27g2000yqd.googlegroups.com> thusl=
y:
[why exceptions?]
int func(parm p,std::string &result)
{
std::string s;
int error;
result = func_1(parm,s);
if (error != OK)
{
return error;
}
error = func_2(s);
if (error != OK)
{
return error;
}
result = s;
return OK;
}
instead of the much simpler
std::string func(parm)
{
return func_2(func_1(parm));
}
This sort of code is profusely present in code that uses COM because
every method on a COM interface typically returns an HRESULT status
code that you should check.
it's the C way there's loads of stuff that works like that. Embedded
SQL, sockets, Win32. Every function returns an error code and you have
to check it.
Result db_update_box_title (Box_id id, const char *title)
{
Box_data data;
Db_conn connection = db_get_connection();
if (connection == NULL)
return E_CANT_CONNECT;
db_read_box (id, &data);
CHECK_DB;
strcpy (data.title, title);
db_write_box (id, &data);
CHECK_DB;
}
Where CHECK_DB did something like
if ((result = sql_error()) != SQL_OK)
return result;
this was actually a concious effort to emulate exceptions. The code
could have been far nastier!
There are three ways I've seen people deal with such error codes:
- ignore them and pretend errors never happen (bad code)
oh yes! At least they have write extra code to ignore exceptions!
- inline handling as above (hard to read code)
- map HRESULTs to exceptions and handle them at the appropriate
boundaries (throwing a C++ exception is undefined when implementing
a COM object, so you have to catch and bubble out HRESULTs)
The latter is the approach I have been teaching for almost 10+ years
now and it dramatically simplifies writing and understanding such
code.