On 12 June 2013 10:31, Neil Morgenstern <[email protected]> wrote: > Another change I made when I worked on the source (which I don't have > available for me now) was to create a specific "deadlock" exception, > which was thrown when a call failed due to database deadlock. This is > handled differently from other exceptions (you resubmit the request) > therefore should throw a different exception type rather than the > general one.
Interesting. I don't think such feature has been considered for SOCI. > In addition we had to change the ODBC exception to put the error > message returned by ODBC into the "what" of the message otherwise it > got lost. The catcher is only dealing with SOCI errors or std > exceptions and not with specific implementation details. Thus an > exception should reflect what went wrong and why, and not be specific > on the implementation detail. > > Error handling is one of those areas where programmers are often lazy > because we expect them not to occur and it is a big effort ensuring > you handle them properly when they do. But hours are spent error > tracking and debugging, and thus handling them properly can save a lot > of users time. The exceptions are minimal sort of by design, with "Don't worry too much about the what() message" [1] principle in mind. I have been thinking on improving it [1] http://www.boost.org/community/error_handling.html There is room for improvement, especially with experience based on std::system_error-like approach, or even exception hierarchies. A while ago we have brainstormed how to improve it and provide information context of error http://thread.gmane.org/gmane.comp.db.soci.devel/7/focus=1075 > In the case of a user using the wrong integral type, it is better that > they fix the code to use the type that matches what the database uses. > So if you are going to enforce it rather than try to convert, then ok. > Of course you could make it some "option" to do that. (Perhaps they > have a lot of old code that now wants to convert to SOCI, and > internally uses integers of the wrong type). If you do report an > error, ensure there is some context. (One of the weaknesses of C++ > actually is that exceptions do not carry call-stack information). I'll keep that in mind, I've recorded your ideas for future reference https://github.com/SOCI/soci/issues/160 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
