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.
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. 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). On Wed, Jun 12, 2013 at 2:06 AM, Lalit Bhasin <[email protected]> wrote: > > Thanks. Good that this is known issue, and would be worked upon in future. > I think I can live with fixing it with some trial and errors . > > / Lalit > > ________________________________ > From: Mateusz Loskot <[email protected]> > To: Lalit Bhasin <[email protected]>; SOCI general discussion list > <[email protected]> > Sent: Tuesday, June 11, 2013 10:05 PM > Subject: Re: [soci-users] bad_cast error (oracle backend) > > On 11 June 2013 08:57, Lalit Bhasin <[email protected]> wrote: >> >> Here is my test code to simulate the problem: >> >> ***************** >> #include <soci/oracle/soci-oracle.h> >> #include<soci/soci.h> >> #include<iostream> >> >> main() >> >> { >> soci::session sql( soci::oracle, "service=XE user=scott password=tiger" >> ); >> soci::rowset<soci::row> rs = ( >> sql.prepare << "select data_length+0, data_length from " >> << " user_tab_cols where table_name = 'TABLE2' "); >> >> soci::rowset<soci::row>::const_iterator it = rs.begin(); >> soci::row const & row = *it; >> std::cout << "DATA_LENGTH + 0 = " << row.get<int>(0) <<std::endl; >> // no error here as expected >> std::cout << "DATA_LENGTH = " << row.get<int>(1) <<std::endl; >> // this gives bad_cast error. Why ?? >> >> } >> ************************* > > I'm afraid you've hit the known nasty deficiency in SOCI integer types: > > https://github.com/SOCI/soci/issues/90 > >> Now when running this executable: >> >> sqlplus> create table table2 ( a number); >> sqlplus> exit >> >> [ubuntu_host]$ ./a.out >> DATA_LENGTH + 0 = 22 >> terminate called after throwing an instance of 'std::bad_cast' >> what(): St8bad_cast >> Aborted >> [ubuntu_host]$ >> >> >> Any idea why I am getting bad_cast error on accessing data_length column >> from user_tab_cols view, even though the column is of type number ? The >> only >> way to access this column is using data_length+0 in select query. > > I presume, one type is signed the other unsigned, and that hits the wall > of quite unfortunately simplified integral conversions in SOCI, currently. > > I'm slowly working (investigating) on getting it right > (https://github.com/SOCI/soci/wiki/RFC1), but I'm too much > multitasking and dealing with unexpected bugfix releases in > meantime. > > The only solution I can suggest is to match the right type by some > trial and error. > I know, I'm sorry :( > > 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 > ------------------------------------------------------------------------------ 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
