troubles with C++ error handling

g_lagaffe

Member²
Hi!
The following code (simplified) tries to insert a row into a logging table. When the table already contains an entry, a dup_val_on_index error should be caught and the logging entry updated with the time of the latest request instead.
The problem is that although the error is triggered, the exception handler is never executed.
Instead a stack overflow error occurs and crashes the program.

Code:
void TClassificationLoader::logrequest(std::string pwpknr)
{
   try{

      loggingQuery->SQL->Clear();
      loggingQuery->DeleteVariables();
      std::string loggingStatement = "Insert into " + requestlogTable +
                                     std::string("(wpknr,wpknrtyp,lastrequest)"
                                     " values('GB0009252882','Isin',to_date('07-11-2005','dd-mm-yyyy'))");
      loggingQuery->SQL->Add(loggingStatement.c_str());
      loggingQuery->Execute();
   }
    catch(EOracleError& e){
      //dup_val_on_index: update time field
      if(e.ErrorCode==dup_val_on_index){
         loggingQuery->SQL->Clear();
         std::string loggingStatement = "Update " + requestlogTable +
                              std::string(" set lastrequest = to_date('07-11-2005') "
                              "where wpknr='GB0009252882' and wpknrtyp='Isin'");
         loggingQuery->SQL->Add(loggingStatement.c_str());
         loggingQuery->Execute();
      }
      else

         throw e; //all other Oracle exception
      }

}
The strange thing is that this code is reused and has been (and still is) working as intended for some time in another program. I already compared the project settings and found no differences.
The stack overflow may have something to do with Array DML, because I see an ExecuteArray call as last call in BC++ call stack window.
I'm using Borland C++ Builder 6.0 and DOA 4.0.6.2
Any hints would be appreciated...
 
Maybe there is some event handler that causes infinite recursive calls?

There is no Array DML involved. The ExecuteArray function is also used to execute a single call (an array of 1).
 
Hello Marco,
Thanks for your quick response!
It definitely seems to be correlated with recursive calls. I stepped into the CPU-Window after the Oracle-exception occured and found out that numerous calls to cc3260mt.___ExceptionHandler are executed. After a bunch of calls (could not find out how many) the push operations at the beginning seem to cause the stack overflow...
I have no idea what causes the error and why these repeated calls occur.
Do you have any clue for me?
 
Back
Top