1

I have written a C++ File Library which have exception and error codes. Exceptions can be disabled when the program is running. In that case, the user have to check the error codes. Of course, when exception throwing is enabled, error code won't be returned because exception is thrown before the called function returns. Currently, exceptions still could be thrown when disabled (bug). I'll fix that soon. Someone comment to me that it is considered bad design to have both exception and error codes. I agree with him and I am about to remove the error codes and have library throw custom derived exceptions with more error information. But I hesitate. I like to have this hybrid approach for performance reasons. This is what I am thinking of doing: keeping exception throwing and error codes but exception throwing is disabled through macro at compile time instead of runtime.

If user define the following in a common config file

#define ELMAX_EXCEPTION 1

The follow code

int Write(std::wstring str) ELMAX_THROW_OR_NOT;

would expand to either of the 2.

// under C++11 compiler
int Write(std::wstring str) noexcept;

// under C++98 compiler
int Write(std::wstring str) throw();

If ELMAX_EXCEPTION is not defined or is zero, the macro would expand to nothing.

int Write(std::wstring) ;

The reason I want to do this, is for library user who wants the performance gain of not having the compiler generating the stack unwinding code (for exception) and compiler can better optimize such functions. My C++ file library is using C file API and the only thing which could throw exception is new keyword, which I intend to add nothrow. The UTF-8 code can also throw exceptions (need to be changed too)

char *parr = new (nothrow) char[num];

if(parr==NULL)
    // handle it either through error code or throw exception (if enabled)

Please kindly advise if I should have a pure exception approach or a hybrid approach (as mentioned), for my library errors. Thank you.

Shao Voon Wong
  • 11
  • 2
  • It really depends upon what kind of library you are thinking about. And it may depend upon the implementation (what compiler, what operating system). Maybe http://programmers.stackexchange.com/ is a better place to ask, but you should be more specific. There cannot be a "one size fits all" answer. For an I/O library, the bottleneck is probably within the actual syscalls, so I would not bother optimizing exceptions. – Basile Starynkevitch Dec 29 '12 at 09:37
  • This is the article link to my library: [Unification of Text and Binary File APIs](http://www.codeproject.com/Articles/465434/Unification-of-Text-and-Binary-File-APIs). It is an open source and portable C++ library. I wrote this file library for my cross-platform XML library (not written yet). When I write this, I have performance in mind: I want my XML library to be as fast as possible. – Shao Voon Wong Dec 29 '12 at 11:40
  • possible duplicate of [Exceptions and error codes: mixing them the right way](http://stackoverflow.com/questions/5805410/exceptions-and-error-codes-mixing-them-the-right-way) – Bo Persson Dec 30 '12 at 12:47
  • "File Library... I like to have this hybrid approach for performance reasons": if you have file I/O code, its performance will be dominated by the cost of I/O, not the cost of error handling. And what makes you think exceptions are expensive? – Raedwald Nov 28 '17 at 12:10

1 Answers1

0

It depends on what you want to do with the library. Obviously exceptions are better from a design point of view, but it's true that they're often disabled for some kinds of apps (such as immersive 3D games).

user1610015
  • 6,561
  • 2
  • 15
  • 18