1

I have a C++ class that spawns a thread that contains an event loop of sorts and the class provides an API to query the list of events that have occurred since the last call, i.e something like std::vector<std::string> getEvents();.

In case some sort of fatal error occurs in the event loop, I shut it down and log an error. I'm trying to figure out how this getEvents() API should communicate that the event loop is no longer running and that it won't return valid output.

Unfortunately, I'm working in an environment where exceptions are disabled so I'm not sure of the best way to handle this. I thought of adding a separate API so the client can query whether or not the event loop is still running but that seemed racy and not ideal.

What's a good approach for designing this?

Update: I think std::optional in C++17 is the best option.

  • What sort of benefit does shutting off exceptions provide? Is this someone's idea of security by obscurity? – Robert Harvey Jun 17 at 18:02
1

I can think of couple of ways of dealing with errors/exceptional conditions when you are not allowed to throw exceptions. They are same in principle but differ in how you use the functions.

  1. Make the return value of any function that could fail to be an int or a suitable enum. This will require you change the function signatures such that what you would return from the function will need to be an output argument.

    int getEvents(std::vector<std::string>& events);
    
  2. Add an output argument to every function that could fail. The type of the argument could be a reference to an int or a suitable enum.

    std::vector<std::string> getEvents(int& errorCode);
    

Both the methods require that you test whether the function succeeded any time you make the call. You proceed to use the real output of the function only if the call succeeded.

When adopting the first approach, use:

std::vector<std::string> events
int status = getEvents(events);
if ( failed(status) )  // Assuming such a function exists.
{
   // Deal with the error.
}
else
{
   // Use events
}

When adopting the second approach, use:

int status = 0;
std::vector<std::string> events = getEvents(status);
if ( failed(status) )  // Assuming such a function exists.
{
   // Deal with the error.
}
else
{
   // Use events
}
0

I'm working in an environment where exceptions are disabled ...

Oh dear.

That's a shame because I'd say that's exactly what you should be using here.

  • Client calls getEvents()
  • getEvents finds that the event loop isn't running and throws an Exception
  • Client deal with ("handles") the fact that the other process is broken.

OK; so you're being told not to use Exceptions.
What are you being told to use instead?

I'm guessing that your fellow Developers have got some method of detecting these "unexpected but thought about" occurrences that the rest of would use Exceptions for...

0

Simple: define an enum for error codes and extend getEvents by an additional "output" argument like getEvents(ErrorCode &errorCode). If you need to return more information than just a number, make ErrorCode a class with all attributes required.

That is a standard way of returning errors in programming languages like C where exceptions are not part of the language.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.