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.
Related
I have an external service I'm calling that just returns 500's with the SAME exception each time no matter the issue.
For example(my api to their service):
Action: Fetch image that does not exist
IMGException: Status code: 500, ErrMsg: File not found
Action: Fetch image that does exist but there are server side issues
IMGException: Status code: 500, ErrMsg: Cannot grab img at this time
Action: Fetch image that does exist but is expired
IMGException: Status code: 500, ErrMsg: Img is expired
What would be the best way to handle this? I was catching them and giving them more descriptive messages to throw to my #ExceptionHandler for logging, etc. Should I just throw them and never catch them since I cannot dependably predict what the exception is caused from and therefore cannot correctly change the status code or message?
You can parse the ErrMsg and throw your own exceptions. But Since the response is from an external service, you can as well include the message from external service in the response to your API in a separate field like ExternalMessage.
This will help the users in case the response from external API changes and you end up throwing a different exception.
I recommend you to simply rethrow these exceptions with the information that the server sends to you and add any information you have. But do not add new information based on what you recieved (with if's, for example), because if they change something your code will just be deprecated.
Of course, never show crypt messages to your final user. In this case add some generic message with instructions about what they can do.
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
I am using library which issues HTTP request by calling
java.net.URL.getInputStream()
In the small portion of requests, it throws IOException. Message of this exception indicates that HTTP Error 500 has been processed.
I am concerned if I am able to get connection error stream from exception. I know that 500 indicates error in the requested API, but I would like to get as many information about error as possible.
I know that
java.net.URL.getInputStream()
is shorthand for
java.net.URL.getConnection().getInputStream()
and I could get error stream from java.net.HttpUrlConnection - but as library does this, it is not available for me.
The library is google geocoder for java, maven artifact
<dependency>
<groupId>com.google.code.geocoder-java</groupId>
<artifactId>geocoder-java</artifactId>
<version>0.16</version>
</dependency>
This is different from question that this question has been marked as duplicate of, as this is not about handling error from java.net.HttpConnection in general, but only in specific case where all I can do is only catching exception - if it is possible to obtain error stream from exception somehow.
I am using GWT. if any server side exception is generated, we are sending an email with error details(have used log4j SMTPAppender). Based on the line number, we can fix the issue..
My scenario is, if any exception is generated in the client package code, as of now, we are giving generic message saying "Some Exception has Occured". But is it possible to display error stack trace along with the exception cause and line number? my code is as below:
GWT.setUncaughtExceptionHandler(new
GWT.UncaughtExceptionHandler() {
public void onUncaughtException(Throwable e) {
Window.alert("Some Exception has Occured");
}
});
I dont think it is possible as client package is converted into Javascript in web mode. Please suggest me if there is any approach to display exception cause and line number where it has occured.
You can read this page
Basically, you have to use JUL to do your logging, and it's client logging : firebug, JS console, etc... You may do some smarter things with the RemoteLogging but i can't help you on that.
The main problem is that log4j is not supported. Maybe with a bridge between JUL and log4j you will be able to achieve everything you want
I would recommend using gwt-log:
Project Page
gwt-log has support for an 'UncaughtExceptionHandler' and a RemoteLogger to send messages/exception to the server.
in gwt-log, you can also turn on the "emulated stack", which is exactly what you want to do:
Wiki Page - Emulated Stack
please note however that this adds a LOT of code to the compiled JS-script
I am building a small api around the JMS API for a project of mine. Essentially, we are building code that will handle the connection logic, and will simplify publishing messages by providing a method like Client.send(String message).
One of the ideas being discussed right now is that we provide a means for the users to attach interceptors to this client. We will apply the interceptors after preparing the JMS message and before publishing it.
For example, if we want to timestamp a message and wrote an interceptor for that, then this is how we would apply that
...some code ...
Message message = session.createMessage()
..do all the current processing on the message and set the body
for(interceptor:listOfInterceptors){
interceptor.apply(message)
}
One of the intrerceptors we though of was to compress the message body. But when we try to read the body of the message in the interceptor, we are getting a MessageNotReadableException. In the past, I normally compressed the content before setting it as the body of the message - so never had to worry about this exception.
Is there any way of getting around this exception?
It looks like your JMS client attempts to read a write-only message. Your interceptor cannot work this way, please elaborate how you were compressing message earlier.