Jaroslav Libak wrote: > I know about _set_new_handler, it's microsoft extension. In ANSI C++ > there is set_new_handler. We could install custom handler in sipxportlib > (in constructor of a static singleton for this purpose), but user could > also set his own handler, in which case our handler wouldnt be called, > as only 1 handler is called.
My point was that set_new_handler() could be used for WinCE (and any other platforms where new() doesn't throw std::bad_alloc) to install a handler that does throw some sort of exception by default. Then the rest of the sipXtapi code could be written without all the cumbersome code to check each return value from new(). At the moment, sipXtapi doesn't catch any std::bad_alloc exceptions either, so on the platforms where new() fails with a std::bad_alloc exception, the exception would simply bubble up to the application code that was invoking the sipXtapi library. This is probably the right thing to do anyway, as only the host application knows enough about the context anyway. It's true the sipXtapi code can't prevent the host application from installing its own new handler. However, this applies to any platform that supports set_new_handler(), not just WinCE. However, if the host application does call set_new_handler(), then it has explicitly accepted responsibility for dealing with the failed allocations. The best thing would be for the sipXtapi documentation to recommend that if the host application does install a new handler, it should refrain from returning control to sipXtapi. In embedded environments, where WinCE is typically used, the methods for handling a failed allocation are likely to be pretty drastic: shutting down the process, or even rebooting, so the fact that the sipXtapi handler doesn't run won't really matter. Stephen C. Steel _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
