Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JmsUtils.buildExceptionMessage throws NPE if the linked exception doesn't have a message [SPR-5275] #9948

Closed
spring-projects-issues opened this issue Nov 6, 2008 · 6 comments
Assignees
Labels
in: messaging Issues in messaging modules (jms, messaging) type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Nov 6, 2008

Anders Wallgren opened SPR-5275 and commented

This method throws an exception if the linked exception's message is null. I've patched it locally as follow:

/**
 * Build a descriptive exception message for the given JMSException,
 * incorporating a linked exception's message if appropriate.
 * @param ex the JMSException to build a message for
 * @return the descriptive message String
 * @see javax.jms.JMSException#getLinkedException()
 */
public static String buildExceptionMessage(JMSException ex) {
	String message = ex.getMessage();
	Exception linkedEx = ex.getLinkedException();
	if (linkedEx != null && (linkedEx.getMessage() == null || message.indexOf(linkedEx.getMessage()) == -1)) {
		message = message + "; nested exception is " + linkedEx;
	}
	return message;
}

Affects: 2.5.6

Issue Links:

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Thanks for pointing this out!

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Guillaume Nodet commented

JmsException.getMessage() can also throw an NPE if the linked exception has no message.
This problem has not been fixed as part of this bug.

@spring-projects-issues
Copy link
Collaborator Author

Guillaume Nodet commented

The current code will throw an NPE if cause.getMessage() returns null.

        public String getMessage() {
 	                String message = super.getMessage();
 	                Throwable cause = getCause();
 	                if (cause instanceof JMSException) {
 	                        Exception linkedEx = ((JMSException) cause).getLinkedException();
 	                        if (linkedEx != null && cause.getMessage().indexOf(linkedEx.getMessage()) == -1) {
 	                                message = message + "; nested exception is " + linkedEx;
 	                        }
 	                }
 	                return message;
 	        }

@spring-projects-issues
Copy link
Collaborator Author

Karim Qazi commented

Looking at the 3.0M1 code this isn't totally fixed. Here is the code I see in the 3.0M1 code base:

public static String buildExceptionMessage(JMSException ex) {
     String message = ex.getMessage();
     Exception linkedEx = ex.getLinkedException();
     if (linkedEx != null) {
          if (message == null) {
               message = linkedEx.toString();
          }
          else if (!message.contains(linkedEx.getMessage())) {  // NPE could still happen here on the contains()
               message = message + "; nested exception is " + linkedEx;
          }
     }
     return message;
}

A null check for "linkedEx.getMessage()" needs to happen or else a NPE can still occur in "!message.contains(linkedEx.getMessage())". This is coded like "someString".equals(null) which will not throw a NPE, but "someString".contains(null) will throw a NPE.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Karim,

That additional not-null check is indeed necessary. Fortunately, it's in there since 3.0 M2 already.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Karim Qazi commented

Ok thanks. When is 3.0 scheduled for release?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging Issues in messaging modules (jms, messaging) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants