All,
I am working on a project to upgrade hibernate from 4.1.4.FINAL to 5.2.17.FINAL. We have a bunch of Sybase stored procedures executed using org.hibernate.jdbc.Work. These stored procedures raise errors with some valid error codes like 20010. The error messages raised are caught and used to display on the UI. Here is the Sybase syntax to raise errors.
raiserror 20005 'Invalid'
I see that the new version of hibernate delegates SQL exceptions to convert to a specific exception in the JDBCException hierarchy. See -
org.hibernate.exception.internal.StandardSQLExceptionConverter
If it doesn't find a specific exception then it creates GenericJDBCException with a default message set. For example see
org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.coordinateWork -
Here the SQL exception is caught and the convert method is called with message 'error executing work'. So genericJDBCException.getMessage() will give this message.
I know that GenericJDBCException.getSQLException().getMessage() will give the actual sql exception message. But it is not feasible to change the existing code.
Is there a way to add our own delegate so that I can check the error code and return an exception with the message in SQLException. Or is there any better way to handle this?
Thanks
Related
https://www.ibm.com/docs/en/db2/9.7?topic=plsql-raise-application-error
I'm getting the following exception in java when my plslq function code uses the RAISE_APPLICATION_ERROR to throw an error to the caller
[[SQL0204] RAISE_APPLICATION_ERROR in *LIBL type *N not found.]
Note:
My code works fine in Db2 for Windows(DB2 LUW)
Expecting an alternate way to implement the custom application error handling.
I have a method that is called during a process by camunda.
I have put a mechanism in this method to show the appropriate error message to the user if an error occurs.
But when this method hits an error, instead of displaying my proper error message, it throws this error message:
Transaction silently rolled back because it has been marked as rollback-only
In fact, camunda converts my type of error, which is a RuntimeException, to UnexpectedRollbackException.
You can see the picture of my sub process, which gets an error during the send Payment stage and should return the appropriate exception message that I wrote, but the exception message itself returns Camunda.
Does anyone have an idea to solve this problem?
Thanks
I'm attempting to provide a useful error message to users of a system where some queries may take a long time to execute. I've set a transaction timeout using Spring using #Transactional(timeout = 5).
This works as expected, but the caller of the annotated method receives a JpaSystemException: could not extract ResultSet exception (caused by GenericJDBCException: could not extract ResultSet, in turn caused by PSQLException: ERROR: canceling statement due to user request).
As far as I can tell, the exception is a result of a statement being cancelled by Hibernate and the JDBC driver once the timeout has been exceeded.
Is there any way I can determine that the exception was a result of the transaction timeout being exceeded so that I can provide an error message to the user about why their query failed?
The application is using Spring framework 4.2.9, Hibernate 4.3.11, and Postgres JDBC driver 9.4.1209. I realise these are quite old. If newer versions make handling this situation easier I would be interested to know.
How about you check the exception message of the cause of the cause against some regex pattern or just checking if the message contains the string like this?
exception.getCause().getCause().getMessage().equals("ERROR: canceling statement due to user request")
If any exception occurs in the code, we have logged the exception using the logback logger.
While logging we have directly passed the exception object e to the error method.
The exception which has been thrown from a third party jar contains sensitive information like username and password.
Currently, we have the username and password as the private field in the code. But it does not seem appropriate to check for check log message do string comparison and then log.
As the exception is thrown by the third party API, fixed pattern for the exception is not known. That's why we are not able to use the %replace.
What is a good way to mask the sensitive data in the exception?
if you can catch/rethrow the exception, wrapp it into one of your own exception, with a String filter on the message.
as a last solution, disable logging from this API packages
I use Java to index some documents with a BulkRequestinto Elasticsearch 1.4.2.
Some of these docs only need to be written when they are not already in the index, so I set the CREATE-opType like this:
indexRequestBuilder.opType(IndexRequest.OpType.CREATE)
Now the docs which were already in the index fail in the BulkResponse.
Error message bulkItemResponse.getFailureMessage():
DocumentAlreadyExistsException[...]
I want to ignore this class of exception but retry writing the docs for all other type of exceptions.
So how can I catch just the DocumentAlreadyExistsException?
I can get the Failure with bulkItemResponse.getFailure(), but I cannot find any information about the type of the Exception beside the error message.
I could look in the error-message for the exception name, but this may be rather fragile with new Elasticsearch versions:
if(bulkItemResponse.getFailureMessage().startsWith("DocumentAlreadyExistsException[")
Is there a better way?
This cant be possible. The bulk request is actaully executed on the server side and not client side. And hence all it can do is to sent the stacktrace back and not the Exception object.