CODEWITHSUNDEEP
javaexceptionsqlexception
WebViewer
WebViewer

Reputation: 811

Statement executed despite exception preceeding it

I have this very simple code snippet which runs as expected if no exception is thrown:

try {
  session = HibernateHelper.getSessionFactory().openSession();
  session.beginTransaction();   
  OracleTables.writeToLogTable(thisLogRecord); // <<<< this throws a java.sql.SQLException!


  boolean isSuccess = OracleTables.writeToActualDataTable(thisDataRecord);
  if (isSuccess) {
    System.out.println("writeToActualDataTable() successful.");
  }
}
catch (RuntimeException e) {
  if (e != null && e.getMessage() != null && e.getMessage().contains("No data to write")) {
    System.out.println("No more data to write.");
    System.exit(0);
  }
  else
    throw e;
}

But if there is some constraint violation in the first database write (e.g. attempt to insert a NULL into a field that doesn't allow it), a java.sql.SQLException is thrown (which is fine) but for some strange reason, the OracleTables.writeToActualDataTable() statement is being executed!

org.hibernate.exception.ConstraintViolationException: could not execute statement
        at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:129)
        at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
        at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125)
        at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110)
        at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:136)
        at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:58)
        at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3067)
        at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3509)
        at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:88)
        at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377)
        at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369)
        at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286)
        at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:339)
        at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52)
        at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1234)
        at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:404)
        at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101)
        at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
        at com.nicecor.test.myclient.OracleTables.writeToLogTable(OracleTables.java:159)
        at com.nicecor.test.myws.ServicePort_ServiceSoapPort_Client.main(ServicePort_ServiceSoapPort_Client.java:180)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.simontuffs.onejar.Boot.run(Boot.java:340)
        at com.simontuffs.onejar.Boot.main(Boot.java:166)
Caused by: java.sql.SQLException: ORA-01400: cannot insert NULL into ("USR"."LOG_TABLE"."CREATE_TMSTMP")

This is strange. I thought an exception in Java would abort execution and go immediately to the catch clause.

What could explain this weird behavior?

What am I missing?

Upvotes: 2

Views: 248

Answers (1)

NESPowerGlove
NESPowerGlove

Reputation: 5496

OracleTables.writeToLogTable() is catching the exception and printing to System.err the contents while continuing execution.

Upvotes: 1

Related Questions