Re: API Exceptions (was: Re: Looking for an elegant way to
convert API methods throwing exceptions to new API methods returning
codes)
On Nov 9, 6:51 pm, "Martin B." <0xCDCDC...@gmx.at> wrote:
On 09.11.2011 07:45, A. McKenney wrote:
[snip]
Every API call had
to be enclosed in a try/catch,
because otherwise there was no
way to tell what step had failed,
and thus no way to even know where
to look to find out what was
wrong or how to recover.
Which *could* be code like that:
try {
conn.open(...);
} catch(APIEx const& e) {
handle_error(e, CONNECTION_OPEN_FAILED);
return;
}
try {
conn.read_data(...);
} catch(APIEx const& e) {
handle_error(e, CONN_DATAREAD_FAILED);
return;
}
// ::: etc.
Now, what I found works better is:
connection_state x(PRE_OPEN);
try {
conn.open(...);
x = OPENED;
conn.read_data(...);
x = DATA_READ;
// ::: etc.
} catch(APIEx const& e) {
handle_error(x, e);
return; // maybe
}
that is, if I need to, I keep track of the state in a separate object
(or more often only via log lines) and when an exception happens, I know
exactly where.
Does that make sense?
I have now became accostumed to using something like this for throwing
exceptions (which uses boost.exception):
[...]
else if(!source)
GNTL_UNWIND_ERROR_INFO(gntl::invalid_ncl_error()
, (typename error::reason<const
char*>::type("No src attribute in media"))
(typename
error::component_identifier<typename
media_traits::identifier_type>::type
(media_traits::identifier(m))));
[...]
with the macro defined as:
#ifndef GNTL_NO_BOOST_EXCEPTION
[...]
#define GNTL_UNWIND_ERROR_EXPAND_INFO_REPEAT(z, n, data) <<
BOOST_PP_SEQ_ELEM(n, data)
#define GNTL_UNWIND_ERROR_EXPAND_INFO(x)
BOOST_PP_REPEAT(BOOST_PP_SEQ_SIZE(x),
GNTL_UNWIND_ERROR_EXPAND_INFO_REPEAT, x)
#define GNTL_UNWIND_ERROR(x) BOOST_THROW_EXCEPTION(x)
#define GNTL_UNWIND_ERROR_INFO(x, y)
BOOST_THROW_EXCEPTION(::boost::enable_error_info(x)
GNTL_UNWIND_ERROR_EXPAND_INFO(y))
#else
#define GNTL_UNWIND_ERROR(x) throw x
#define GNTL_UNWIND_ERROR_INFO(x, y) throw x
#endif
The BOOST_THROW_EXCEPTION adds line code and filename to the exception
information. If the information will be used for debugging, this is
usually enough. If a report to the user must be written, I try to give
as much information as possible at the throw site.
But if the exception is thrown by something else and I must know
which, then Martin's organization is what I find better suited. Also,
I try to make this failed state as part of the object's value which
can be verified somehow, so I can create a predicate to find out what
happened by way of the object's state, instead of by current position
in the code since this will be lost when the exception is thrown.
Something like this:
connection conn (/*args*/);
try
{
conn.open(...);
x = OPENED;
conn.read_data(...);
x = DATA_READ;
// ::: etc.
}
catch(APIEx const& e)
{
if(!conn.is_open())
handle_failed_open_error(x, e);
else
if(conn.some_other_predicate_for_expected_state_when_read_fails())
handle_read_data_error(x, e);
[...]
return; // maybe
}
This allows me to think of the application's state by which entities
the object's current value represents, opposed to what is currently
being run. This might not always be possible, it can be costly to
do this for some abstractions.
cheers,
Martin
--
I'm here to learn, you know.
Just waiting for someone,
to jump from the shadows,
telling me why I'm wrong.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]