We Keep Coding

Differences between error methods in log4j 1.x

In the logging part of the project I working for, I try to optimize the error messages that are shown in log management. Logging error messages is coded like this:
String errorMessage =" Problem with server "+"\n"+t.getMessage();
_logger.fatal(errorMessage);
Where t is a Throwable object and _logger is a Logger object, which is related to the log4j framework.
What I wonder is, what changes if I use _logger.fatal(errorMessage, t); instead of _logger.fatal(errorMessage);? If there is a major difference between them, Which one will be better to use?
Edit: I've just realised I copied "fatal" example instead of "error". However my question is same for fatal, too.

Practically all Java logging framework (alas, we have plenty of those...) support putting a Throwable as the last parameter.
This will result in a stack trace being logged, which can be extremely useful in diagnosing and fixing the problem.
I'd only ever not give the exception to the logger if the cause of the exception is really well established and printing the exception is just unnecessary noise. For example here:
try {
int port = Integer.parseInt(input);
// do something with the port
} catch (NumberFormatException e) {
logger.error("'{}' is not a valid port number: {}", input, e.toString);
}
Another case is when the exception is being re-thrown (and something else will eventually log it with more detail).
But not with a "Problem with server" (and at FATAL level no less). That looks like you want to get as much info as you can get.
Also note that in those cases, e.toString() is usually better than e.getMessage() because it also includes the name of the exception in addition to its message (which may be empty).

Location of logs for java.util.logger

I am on windows, and using squirrel client to access a database on informix.
On my jsp pages there are code that open the databse informix for query.
Other than out printing the error message on the webpage where the code is eg: the code is in file DB123.jsp, then the error message can be printed out at //100.100.100.100/DB123.jsp on browser.
My question is if I have a java.sql.SQLException, where else can I look at more detailed error message, or what configuration should I make to have it enabled? Because sometimes sql error unable to be printed on the webpage.
The code at DB123.jsp with the log:
public Logger myLog = Logger.getLogger("DB123.jsp");
{...}
catch(SQLException sqle){
strMsg = "failed";
strMsgDesc = ERR_SERVICE_NOT_AVAILABLE+sqle; 　//this one out print on webpage
myLog.error(sqle.getMessage()); 　//This line i dont know where it logs to
}...
array.put("msgdesc", strMsgDesc);
out.print(array);
/***end****/
If there is a syntax error on sql statement, the flow of the program should stopped at sql.executeQuery(); right? So the logging of error should be on the dev environment server, there wont be any thing to be debug at informix server right? So IBM interactive debugger would not help here.
Whenever I google 'location of logs of java.util.logging' or a similar phrase, I could not get any good explanation. Many searches returns codes of how to setup the logger, but not where the logs are.
Any help is much appreciated.

Catch a specific Elasticsearch exception from a BulkRequest

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.

RuntimeException does not halt GAE but returns HTTP 500 when run locally

Let me first provide some background information. If you don't care you can skip to the next paragraph. I wanted to use the DrEdit sample Java application which is integrated with Google Drive as the basis of my application. I need to refactor the code, though, because the original scenario assumed that the user would only access the application through the Drive and never directly. Currently when the latter happens, a RuntimeException is thrown which should not be the case in a normal flow.
Thanks to that issue I stumbled upon a difference between my local environment and the GAE which is manifested when the following code is run:
} catch (CredentialMediator.NoRefreshTokenException e) {
try {
resp.sendRedirect(e.getAuthorizationUrl());
} catch (IOException ioe) {
throw new RuntimeException("Failed to redirect user for authorization");
}
throw new RuntimeException("No refresh token found. Re-authorizing.");
}
When I run this application on GAE, the RuntimeException is thrown (I can see it in the logs) and the sendRedirect is also executed so I get to see the page that should be displayed.
However when I run the same application locally, I get the HTTP 500 error and the RuntimeException is displayed but the sendRedirect is ignored.
So far I haven't been successful in finding an explanation for this behaviour. I would like to know why this is the case and if there are settings that I can change in order to fully replicate the GAE environment locally.

This is how standard defines the sendRedirect(). It actually commits the response so after calling this method you should not be able to change or add to the response. However it does not define what happens if you trigger an exception after redirect.
Anyway, your code is ambiguous on purpose - you should not continue processing the request and throw exceptions after sending redirect. If you have any processing to do, then do it before redirect.
OTOH you should not rely on generic exception handling. Instead install a servlet filter that catches exceptions and return a proper user-readable or device-readable response.

Display servlet errors in JSP using JSTL or EL

I want to display error messages e.g SQLException errors in the jsp page that the servlet has redirected to. I am new in java and JSP but I have managed to get basic things like saving data using a servlet to a database working. Below is my code for catching errors encountered
catch(SQLException e){
out.println("SQL Error encountered "+e.getMessage());
How can I catch this error into a jsp page that has been redirected to by the servlet using jstl or Expression Language? E.g if an admin submits a duplicate email address from a page called createuser.jsp, the error should be displayed in creatuser.jsp

You should never post exception related material to your front end since this can provide information on your internal structure and underlying architecture which is never a good idea since it could lead to possible attacks.
What you could do would be to do some sort of form validation, as shown in here and, as in your case, instead of showing exception messages, you simply make a check for the name and if it throws and exception, just display a message on the screen something like so: User Already Exists!. Error messages such as these are usually also less confusing for non technical people.

You can add the message as an attribute of your request:
Servlet:
catch(SQLException e) {
request.setAttribute("exception", "SQL error encountered");
}
Jsp:
${exception}