error vs exception : design problem

[valblade]

Hi everyone,

I'm actually trying to solve the question of error vs exception.

In my functions library, performance is not the key value. The realy important thing is to provide "easy to use interface".

For example, I have the following non-member non-friend function :

namespace process
{

   kill(pid_type   pid);

} //! namespace process 

there is no pre-conditions to call this function, so, these errors can occur :
* pid does not exists
* permission denied
* cannot terminate process

Actualy, error are reported by throwing exceptions.

try
{
   process::kill(pid);
} 
catch (const boost::system::system_error& err)
{
  //do something
}

But the user code is becoming so littered with try-catch blocks as to be unmaintainable.

So, like the boost::filesystem V3, I would like to provide a dual interface :

process::kill(pid_type   pid);  //throw
process::kill(pid_type   pid, boost::system::error_code& error);  //nothrow 

I don't know what is the best design to provide both interfaces and don't repeat myself.

I thought about the following solutions :

unique higher interface :

process::kill(pid_type   pid, boost::system::error_code* error = NULL);
//try...catch the original call and report by filling error argument if not null, 

But I also have another idea :

Can a policy based design help here?
I mean : a kind of error-reporting policy...?

If it's possible, how does this kind of solution look like?

I prefer a full static solution than a dynamic one.


Thanks for your help!

--
valblade

[jsmith]

Generally, when building a library it is not a good idea to leak exceptions to the user code. This is because the user
code isn't guaranteed to catch the exception unless it is compiled with same version of the same compiler as the
library.

That said, Alexandrescu and Sutter write, in C++ Coding Standards, that if the immediate caller of the function
is always the entity that handles the error, then exceptions are contraindicated in this case, and return values
should be used instead.

Some people also say that exceptions are to be used in exceptional cases only -- ie, only when very rare
errors occur. Since the user should be expected to pass in a non-existent pid to your kill function, this should
not be treated as an exceptional error case.

If you still want to provide a dual interface, then I would have the throwing version of your function call the
non-throwing version (or else both just call an internal function that returns an error code w/out using exceptions.)