Jump to content
  • Advertisement
Sign in to follow this  
littlekid

Is it ok for a release version of a library to not throw exceptions

This topic is 3235 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 ;)

Share this post


Link to post
Share on other sites
interesting ideas.

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);
}

Share this post


Link to post
Share on other sites
Quote:
Original post by littlekid
I am inclined to think just a logging would be efficient enough.
Once 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 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]

Share this post


Link to post
Share on other sites
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:
typedef void* (*FnAlloc)( size_t );
typedef void (*FnFree )( void* );
typedef void (*FnError)( char* );
//Called by the user
void MyMiddleware_Init( FnAlloc, FnFree, FnError );

//Called internally by the library
void* 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 );
}

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!