Is it ok for a release version of a library to not throw exceptions
Author
Is it ok for a release version of a library to not throw exceptions? What about a debug library. Should a debug library throw exceptions in cases of error/warning like invalid arguments, out of range etc, or should it just use a logging mechanism which output all errors/warning to a log file where users can then look at the log file to see what went wrong
regards
It depends ;)
I personally only use exceptions for fatal errors, which shouldn't ever occur in the final, tested, debugged, shipping version of a program. So I would be ok with exception handling being completely removed from release builds. This is in C++ though where exceptions are fairly expensive to use.
In other languages, like Java, exceptions are more commonplace and it would probably be expected for a library to let the client know about any exceptional circumstances that have occurred.
I personally only use exceptions for fatal errors, which shouldn't ever occur in the final, tested, debugged, shipping version of a program. So I would be ok with exception handling being completely removed from release builds. This is in C++ though where exceptions are fairly expensive to use.
In other languages, like Java, exceptions are more commonplace and it would probably be expected for a library to let the client know about any exceptional circumstances that have occurred.
Author
thanks for the replies, well my scenario is this, I am writing a library/dll and I am releasing 2 builds for it, 1 is a release build and 1 is a debug build. The debug build is used when users are using the library for development purpose and when done, they switch to a release build.
Hence I was wondering what serve best as a error reporting scheme for the debug build, say if the user supply a wrong arguments e.g an invalid pointer, currently in the debug build the logger would log it but the program would crash something like. If I am to use exceptions, the user might have a chance to catch the exception and handle it, but if the user doesn't catch the exception, the program would still crash.
However I do intend to remove all logging and exceptions throwing from the release builds.
Is this a suggested approach? or am I taking/viewing things wrongly?
edit: the more ponder the more i think i should avoid throwing exception since at the end of the day, users are going to switch to the release build, and if initially they encase everything in try/catch blocks it would become redundant when they switch to a release build. Hence I am inclined to think just a logging would be efficient enough. Is this a logical approach to view the problems at hand??
regards
Hence I was wondering what serve best as a error reporting scheme for the debug build, say if the user supply a wrong arguments e.g an invalid pointer, currently in the debug build the logger would log it but the program would crash something like. If I am to use exceptions, the user might have a chance to catch the exception and handle it, but if the user doesn't catch the exception, the program would still crash.
However I do intend to remove all logging and exceptions throwing from the release builds.
Is this a suggested approach? or am I taking/viewing things wrongly?
edit: the more ponder the more i think i should avoid throwing exception since at the end of the day, users are going to switch to the release build, and if initially they encase everything in try/catch blocks it would become redundant when they switch to a release build. Hence I am inclined to think just a logging would be efficient enough. Is this a logical approach to view the problems at hand??
regards
You could allow the users of your library to specify an "on error" callback function.
Then they could link any errors that occur inside your library into their own logging/assertion/exception system. By default, you could make this callback point to a function that writes errors to a file, but if your users don't like that behaviour, they can specify their own error-handing function instead ;)
Then they could link any errors that occur inside your library into their own logging/assertion/exception system. By default, you could make this callback point to a function that writes errors to a file, but if your users don't like that behaviour, they can specify their own error-handing function instead ;)
Author
interesting ideas.
To Hodgman: hmm just clarifying does that mean you have an error callback for each function in the library? e.g
To Hodgman: hmm just clarifying does that mean you have an error callback for each function in the library? e.g
class SampleLibrary{public void CreateBlob(BLOB_DESC& desc, ErrorCallbackFuncPtr errorCallback); void CreateFile(FILE_DESC& desc, ErrorCallbackFuncPtr errorCallback);}Quote:Original post by littlekidOnce you log the problem, what then? If they've passed in invalid arguments, for example, what can you do, other than throw some kind of exception?
I am inclined to think just a logging would be efficient enough.
I suppose if they pass in NULL, you can just wait until your code tries to dereference that pointer and it'll crash then, but if that doesn't happen for a while, it might be difficult for the user of your library to trace that back to the NULL pointer they passed in 5 function calls ago (although the purist in me says that if a parameter cannot be NULL, you should be using a reference instead of a pointer, but that's a topic for another discussion, perhaps...)
I would suggest that whatever you do, you do in both release and debug versions.
[Edited by - Codeka on December 7, 2009 12:36:38 AM]
No, a global setting for your whole library.
I've seen other middleware libraries use something like the following to give the user more control over how the library integrates with the host application:
I've seen other middleware libraries use something like the following to give the user more control over how the library integrates with the host application:
typedef void* (*FnAlloc)( size_t );typedef void (*FnFree )( void* );typedef void (*FnError)( char* );//Called by the uservoid MyMiddleware_Init( FnAlloc, FnFree, FnError );//Called internally by the libraryvoid* MyMiddleware_Alloc( size_t );void MyMiddleware_Free ( void* );void MyMiddleware_Error( char* );void* Default_Alloc( size_t size ) { return malloc( size ); }void Default_Free ( void* p ) { free( p ); }void Default_Error( char* text ) { printf( text ); }FnAlloc g_fpAlloc = &Default_Alloc;FnFree g_fpFree = &Default_Free;FnError g_fpError = &Default_Error;void MyMiddleware_Init( FnAlloc a, FnFree f, FnError e ){ g_fpAlloc = a; g_fpFree = f; g_fpError = e;}void* MyMiddleware_Alloc( size_t s ){ return g_fpAlloc( s );}void MyMiddleware_Free( void* p ){ g_fpFree( p );}void MyMiddleware_Error( char* t ){ g_fpError( t );}
Author
Thanks for the replies. =)
To Codeka, I can't have it in both release and debug version as suggested as the logging system itself makes the program runs up to 80% slower. (I am using an XML logging mechanism borrowed from an article in here). Furthermore, in debug mode, I am doing extensive checking for the whole code which could be simplified in the release builds as I would assume a more stable code from the user at that stage. For e.g in a release build I would more or less assmue the user to be writing within the valid length of a buffer. Thanks for the suggestion though =)
Thanks
To Codeka, I can't have it in both release and debug version as suggested as the logging system itself makes the program runs up to 80% slower. (I am using an XML logging mechanism borrowed from an article in here). Furthermore, in debug mode, I am doing extensive checking for the whole code which could be simplified in the release builds as I would assume a more stable code from the user at that stage. For e.g in a release build I would more or less assmue the user to be writing within the valid length of a buffer. Thanks for the suggestion though =)
Thanks
On a slight tangent, whatever the differences between your release and debug libraries, I would be very unlikely to use either one without access to the source code. No amount of logging makes up for a debugger and source code, especially when there is the possibility that the bug is in your library...
At the very least, I would expect the debug build to be compiled with debug symbols turned on, and the release build to be accompanied by an external debug symbol file (or whatever the equivalent is for your compiler).
At the very least, I would expect the debug build to be compiled with debug symbols turned on, and the release build to be accompanied by an external debug symbol file (or whatever the equivalent is for your compiler).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
