My method makes an update on the database, and then after it tries to send an email, the latter could go into exception, and when it goes into exception, the database is not updated. How can I solve? Thanks in advance
userRepository.save(user);
if (user.isAccepted()) {
try {
mailSender.sendEmail(user);
} catch (Exception e) {
throw new MailToNotFoundException(ex);
}
}
Related
In my application I have a structure where methods are overloaded. One method does not have Connection as a parameter while the other one has. The one without is only used to create a database connection and then call the other one.
In this example, let's say i call the first method below to create a new user:
#Override
public User handleCreate(User item, boolean silent) throws DAOException {
Connection conn = null;
try {
conn = daoFactory.getConnection();
return handleCreate(conn, item, silent);
} catch (SQLException ex) {
rollback(conn);
close(conn);
throw new DAOException(ex);
} finally {
commit(conn);
close(conn);
}
}
and the other one that has Connection as a parameter:
#Override
public User handleCreate(Connection conn, User item, boolean silent) throws DAOException {
try {
boolean hasError = false;
conn.setAutoCommit(false);
item.setUsername(item.getUsername().trim());
if (item.getId() == 0) { // Not registered user
if (userDAO.existByName(conn, item.getUsername())) { // Username already exist
msg.setErrorMessage(MessageHandler.getMessage("user.create.error.userAlreadyExist"));
hasError = true;
}
if (userDAO.existEmail(conn, item.getEmail())) { // Email already exist
msg.setErrorMessage(MessageHandler.getMessage("user.create.error.emailAlreadyexist"));
hasError = true;
}
if (!hasError) { // No unique violations
Integer id = userDAO.create(conn, item); // Create
item.setId(id);
msg.addMessage(MessageHandler.getMessage("user.create.completeMsg"));
}
} else { // Registered user
msg.setErrorMessage(MessageHandler.getMessage("user.create.error.userAlreadySet"));
}
commit(conn);
close(conn);
return item;
} catch (SQLException ex) {
rollback(conn);
close(conn);
throw new DAOException(ex);
} catch (DAOException ex) {
rollback(conn);
close(conn);
throw ex;
} finally {
commit(conn);
close(conn);
}
}
What I'd like to ask about is what's best practice. I believe I'm overdoing the catching and I'm not sure how to reduce rollback, close etc. in the catch clauses without risking unhandled errors. I also would like to ask if it's best practice to commit and close the transaction/connection where you actually started it - in this case the first method.
Any insight to best practices in this would be much appreciated, or maybe you know another already answered question similar to mine that I haven't found.
If there is an exception, there won't be any changes and you don't have to rollback. You can simply close the connection. Commit at the end is a good practice. If you want best practices, you will have to put a try catch against the close too. And I don't think you can pass connection as a parameter to rollback and commit.
I am using SonarQube for code quality. I got one issue related to exception handling, which says remove throw clause from finally block.
} catch(Exception e) {
throw new MyException("request failed : ", e);
} finally {
try {
httpClient.close();
} catch (IOException e) {
throw new MyException("failed to close server conn: ", e);
}
}
Based on my understanding above code looks good. If I remove throw clause and suppress exception in finally then caller of this method will not be able to know server's status. I am not sure how we can achieve same functionality without having throw clause.
Your best shot is to use the Automatic Resource Management feature of Java, available since Java 7. If that is for some reason not available to you, then the next best thing is to replicate what that syntactic sugar expands into:
public static void runWithoutMasking() throws MyException {
AutoClose autoClose = new AutoClose();
MyException myException = null;
try {
autoClose.work();
} catch (MyException e) {
myException = e;
throw e;
} finally {
if (myException != null) {
try {
autoClose.close();
} catch (Throwable t) {
myException.addSuppressed(t);
}
} else {
autoClose.close();
}
}
}
Things to note:
your code swallows the original exception from the try block in case closing the resource fails. The original exception is surely more important for diagnostic;
in the ARM idiom above, closing the resource is done differently depending on whether there already was an exception in the try-block. If try completed normally, then the resource is closed outside any try-catch block, naturally propagating any exception.
Generally, methods in the finally block are 'cleanup' codes (Closing the Connection, etc) which the user does not necessarily need to know.
What I do for these exceptions is to absorb the exception, but log the details.
finally{
try{
connection.close();
}catch(SQLException e){
// do nothing and just log the error
LOG.error("Something happened while closing connection. Cause: " + e.getMessage());
}
}
You're getting a warning because this code could potentially throw an exception while dealing with a thrown exception. You can use the try with resource syntax to close the resource automatically. Read more here.
In the case that the "request failed : " exception is thrown and you fail to close the httpclient, the second exception is the one that would bubble up.
I am not sure how we can achieve same functionality without having
throw clause.
You could nest the two try blocks differently to achieve the same result:
HttpClient httpClient = null; // initialize
try {
try {
// do something with httpClient
} catch(Exception e) {
throw new MyException("request failed : ", e);
} finally {
httpClient.close();
}
} catch (IOException e) {
throw new MyException("failed to close server conn: ", e);
}
I have a piece of code that has driven me nuts.
The general flow is that when a certain event in TRY occurs, I throw the exception... according to my understanding, whenever the throw is called, it simply stops further execution in the same class and return the control back from where this class's function was called...
Here is the code...
try{
session = getHibernateSession();
companyAccountLinkingWSBean = (CompanyAccountLinkingWSBean) wsAttribute
.getBeanObject();
companyToMatch = companyAccountLinkingWSBean.getCompanyCode();
cnicToMatch = companyAccountLinkingWSBean.getCnic();
LOG.debug("We have found the Mobile number from the WS Bean as input");
mobile = companyAccountLinkingWSBean.getMobileNumber();
LOG.info("Mobile is : " + mobile);
if(mobile.isEmpty()){
LOG.info("Coming in mobile.isEmpty()");
companyResponceWSBean = new CompanyResponceWSBean();
companyResponceWSBean.setpID(Constants.INPUT_MOBILE_ERROR);
companyResponceWSBean.setMessage(Constants.INPUT_MOBILE_ERROR_MSG);
companyResponceWSBean.setSuccess(false);
response = new WSAttribute();
response.setBeanObject(companyResponceWSBean);
LOG.info("BEFORE THROWING");
throw new PayboxFault(Constants.INPUT_MOBILE_ERROR,
Constants.INPUT_MOBILE_ERROR_MSG);
}
LOG.info("Out side IF statement!!");
} catch (Exception e) {
LOG.info("IN Exception!!");
}
LOG.info("Out Side Exception . . . Before Returning ");
return response;
Output in LOG When Empty mobile field is given as input ...
We have found the Mobile number from the WS Bean as input
Mobile is :
Coming in mobile.isEmpty()
BEFORE THROWING
IN Exception!!
Out Side Exception . . . Before Returning
How is it actually possible?
Your understanding isn't quite correct. Catching an exception handles it, and after the catch is completed, flow will continue after the try/catch, unless you throw another exception, or re-throw the exception. This might explain it better:
try {
// Happy case flow here ...
throw new PayboxFault(...);
// If an exception is thrown, the remainder of the `try` block is skipped
} catch (Exception e) {
// The exception is now handled ...
// Unless a new exception is thrown, or the caught exception re-thrown
} finally {
// Code here should always be called after the try OR catch block executes,
// Finally is called even if the catch re-throws
}
// Code after the try-catch-finally executes if the try completes successfully
// OR if the exception is handled in the catch, but not if the catch re-throws
When you catch an exception, execution continues from after the catch block. If you don't want it to, you'll need to return from inside your catch (or not catch the exception at all and let it bubble up to the caller).
catch (Exception e)
{
LOG.info("IN Exception!!");
return null;
}
Or:
catch (Exception e)
{
...
throw e; // rethrow exception.
}
Note that if you do this, the exception will continue to bubble up the call stack until you catch it somewhere else (such as in the calling method).
You are catching the Exception. So it will not transfer back the control to the calling function unless entire function is executed.
If you want to skip the
LOG.info("Out Side Exception . . . Before Returning ");
statement you can do
catch (Exception e) {
LOG.info("IN Exception!!");
throw e;
}
And about
when ever the throw is called, it simply stops further execution in the same
class and return the control back from where this class's function was called...
Yes only if you do not catch it. You catch an Exception if you intent to do something with it which includes logging it and rethrowing.
Just came across a rather confusing exam question, and my lecturer is away on holidays, so I come to StackOverflow begging for help!
The question is as follows :
"Joe has his own JoeConnection class for making connections between his computer and other computers. The class provides the following constructor and instance methods :
JoeConnection( String address ): Make a connection with the URL address.
void writeLn( String text ) : Write text to the JoeConnection.
String readLn( ): Read a line of text from the JoeConnection.
void clode( ) : Close the JoeConnection.
Joe's connections regularly fail and this causes errors. Using proper exception handling, demonstrate how to use Joe's JoeConnection class to
make a JoeConnection with the URL http://students.chat.box
write "Hello world" to the JoeConnection
read in a string from the JoeConnection
close the connection.
The connection handling should provide as man details as possible about the cause of failure and print the stack trace which led to the failure.
I have no idea how to tackle this, but I assume it is something similar to this :
public class Test {
try {
JoeConnection connection = new JoeConnection(http://students.chat.box);
} catch {
connectionError e; printStacktrace();}
}
}
Can anyone please help me figure this out? Thanks a lot.
Without an indication of what exceptions are thrown and why, the only proper exception handling is no handling at all. Don't catch an exception if you don't know how to fix the problem that triggered it.
But the further instructions in your assignment introduce a different notion of "proper." You're supposed to print a stack trace. So catch the exception and print a stack trace. You were on the right track, but your syntax was wrong. Refer back to your textbook and lecture notes to remind yourself what the syntax is for catching exceptions (and for passing strings to functions, for that matter).
try {
JoeConnection connection = new JoeConnection("http://students.chat.box");
connection.writeLn("Hello world");
// etc
} catch (Exception e) {
e.printStackTrace();
}
"Proper exception handling" is a little vague. I agree with #Rob Kennedy's statement that no exception handling is appropriate unless you know why the exception is thrown and what should be done with it. Otherwise, the exception should be allowed to propagate. So, for example:
void foo(String address) throws JoeException {
JoeConnection connection = new JoeConnection(address);
try {
connection.writeLn("Hello World!");
} finally {
// Ensure the connection is closed when finished.
// This happens whether an exception occurs or not.
connection.close();
}
}
If you wanted to catch the exception just to print it, you could do something like this:
void foo(String address) throws JoeException {
try {
JoeConnection connection = new JoeConnection(address);
try {
connection.writeLn("Hello World!");
} finally {
connection.close();
}
} catch (JoeException e) {
e.printStackTrace();
// Don't know what to do about this; rethrow.
throw e;
}
}
There is a subtlety here that even experience Java programmers can miss, though. If an exception occurs while creating the connection, it doesn't need to be closed. If an exception occurs while writing to the connection, it does need to be closed; thus the finally clause. However, the act of closing can also throw an exception. If closing the connection throws an exception, only that exception will be thrown by the try statement. If the finally clause was reached as a result of the writeLn operation throwing an exception, the exception of the writeLn call will be effectively ignored. This is probably not what you want.
Instead, we can try something ugly like this:
void foo(String address) throws JoeException {
try {
JoeConnection connection = new JoeConnection(address);
boolean normalCompletion = false;
try {
connection.writeLn("Hello World!");
normalCompletion = true;
} finally {
if (normalCompletion) {
// The writeLn operation completed normally.
// Propagate an exception thrown by the close operation.
connection.close();
} else {
// The writeLn operation completed abruptly.
// Ignore an exception thrown by the close operation.
try {
connection.close();
} catch (JoeException e) {
/* empty */
}
}
}
} catch (JoeException e) {
e.printStackTrace();
// Don't know what to do about this; rethrow.
throw e;
}
}
This looks (and is) syntactically hideous, but it does show "proper" exception handling of a sort. The language enhancement from Project Coin should clean this up a bit.
For starters, I can help you out with the syntax of what you wrote:
try {
JoeConnection connection = new JoeConnection("http://students.chat.box");
}
catch (JoeConnectionException e) {
e.printStacktrace();
}
I took the liberty of changing the linebreaks and renaming 'connectionError' as JoeConnectionException which looks more conventional to me.
You'll have to do something similar for the readLn, writeLn, and close method calls since it said that the connection regularly fails (i.e. not just while connecting).
Cheers, good luck.
Catching an exception should look like:
try {
JoeConnection conn = new JoeConnection(url);
} catch (YourExceptionClassNameHere e) {
e.printStackTrace();
}
Also: if you want to use a literal String, make sure you include the quotations. (It should be "http://students.chat.box".)
It's good to have a finally as well:
public class Test {
try {
JoeConnection connection = new JoeConnection(http://students.chat.box);
}
catch(Exception e) {
e.printStacktrace();
}
finally {
if(connection != null) {
connection.close();
}
}
}
Typically you handle exceptions if you know what to do with them (this involves error-recovery logic or wrapping an exception and throwing it to a higher level).
Assuming that each method throws an exception, you could do something like this for "maximum detail":
public class Test {
JoeConnection connection = null;
try {
connection = new JoeConnection("http://students.chat.box");
...
...
}
catch(OpenException e) {
System.out.println("Error while opening connection");
e.printStacktrace();
}
catch(WriteException e) {
System.out.println("Error while writing to connection");
e.printStacktrace();
}
catch(ReadException e) {
System.out.println("Error while reading from connection");
e.printStacktrace();
}
finally {
if(connection != null) {
connection.close();
}
}
}
I have a method that looks like this:
try {
doStuff();
} catch (Exception ex) {
logger.error(ex);
}
(I don't really use method names like doStuff - this is just to make things easy)
In doStuff I do a variety of things, among them is call a data access method (so, another method within doStuff) that ends with the following:
} catch (SQLException ex) {
logger.error(ex);
} finally {
try {
connection.close();
proc.close();
results.close();
} catch (Exception e) {
logger.error(e);
} //<--Exception thrown here. HUH?
}
return stuff;
When stepping through this code I get to the second to last curly brace (marked with a comment) and then jump up to the catch in the first code block with a NullPointer exception. The results.close() is what is being run right before it (results is not null). My IDE (NetBeans) doesn't provide a stack trace (it shows the stack trace is null) or any other information other than the name of the exception (from what I can tell).
This code was running fine previously. In fact while it was running, I changed the stored procedure that the data access method (where I'm getting this exception) was calling, and then this error started to occur (without the application having been stopped at all). I've since tried rebuilding and restarting but to no avail. I could change the sproc back but I really want to find out what this error is from since it makes no sense that the sproc would even be a part of this considering where in the code the exception is occurring.
your doStuff() method is throwing something other than a SQLException and it is not being caught. add a catch(Exception e) block and log that exception and see what happens.
this code sample exhibits the same behaviour you are describing:
public class TryCatchTest {
public static void main(String[] args) {
try {
System.out.println("foo");
throw new NullPointerException();
} finally {
try {
System.out.println("bar");
} catch (Exception e) {
e.printStackTrace();
}
} // exception thrown here
}
}
Close the resources in the reverse order in which they were obtained:
try
{
results.close();
proc.close();
connection.close();
}
catch (Exception e)
{
logger.error(e);
} //<--Exception thrown here. HUH?
I'd also recommend methods like these:
public class DatabaseUtils
{
// similar for ResultSet and Statement
public static void close(Connection c)
{
try
{
if (c != null)
{
c.close();
}
}
catch (SQLException e)
{
// log or print.
}
}
}
It could well be that logger is null.
Hard-to-pinpoint exceptions are often thrown in the exception handler itself.
NullPointerException can not be thrown in a line without a statement.
Check that the class file you are executing is of the same version as the source you view (I have had similar issues when an incorrectly configured classpath contained a class twice and the older version was found first in the classpath, or a recompiled class files for not correctly copied to the web container I used for testing).
Edit: As emh points out, it could also be that exception occured prior to entering the finally block.
I'm 99% sure this is happening in the JDBC driver. For starters, your close statements are backwards. You should close the resultset, the statement and the connection, in that order.
If you are running in an application server which is managing the transactions, then the attempt to commit the transaction may trigger the exception inside the JDBC driver.
It could also be something about how result sets are generated in the stored proceedure, such as accessing one, then accessing another, and then referring back to the first one.
As I said in a comment, never catch an exception that you don't want to deal with. In your code, assuming that it is complete, you are not doing anything interesting with the exception, and it is causing you confusion on where and why the exception is happening. If you really want to do more than log or printStackTrace(), like wrapping it with a domain-specific exception (like your.package.DataAccessException or something), then great.
Do something more like this:
ResultSet results = null;
CallableStatement proc = null;
Connection connection = null;
try {
connection = >
proc = connection.createCallableStatement(..);
results = proc.execute(..);
>
} finally {
try {
if ( results != null ) {
results.close();
}
} catch (Exception e) {
logger.error(e);
}
try {
if ( proc != null ) {
proc.close();
}
} catch (Exception e) {
logger.error(e);
}
try {
if ( connection != null ) {
connection.close();
}
} catch (Exception e) {
logger.error(e);
}
}
And then in the caller:
try {
doStuff();
} catch ( SQLException e ) {
throw new your.package.DataAccessException(e);
// or just let the SQLException propagate upward
} catch ( Exception e ) {
throw new your.package.AppException("omg, crazy pills!", e);
// or, once again, just let the exception
// propagate and don't catch anything
}
So, take-away:
don't log exception where they happen, just pass them on, nested in another exception. You don't want your process to not know whether or not the SQL action succeeded or not. You would rather stop and do something else.
Nest exceptions until the get to the end of the line, that way, you always have the complete trace in the place that you wanted to deal with the exception, not in five places scattered throughout your server log.
Nest exceptions (yes, I said that twice!) so that you don't care where the JVM actually throws the exception from, you have the next exception to follow, telling you it was actually a callable statement, or improper closing of your resources, etc.
Don't nest and throw exceptions from errors caught in your finally code, that will interfere with the original exception and that will be more interesting than the failure to close and statement that didn't get opened in the first place.
Set variables to null before you use them, and then check for null before close()ing them.
Catch each problem in the finally block individually, as you might not be able to close your ResultSet (because some execution error caused it not to open in the first place), but you should still try to close the CallableStatement and Connection, as it is probably unaffected and will still cause you to leak resources.
Hope that helps.