[
https://issues.apache.org/jira/browse/ARTEMIS-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322550#comment-16322550
]
ASF GitHub Bot commented on ARTEMIS-1601:
-----------------------------------------
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1772
The NPEs occur that's why I opened this PR. Since they are only logged in
debug level I only saw them while debugging some stomp issue I had.
Throwing an exception is a relatively expensive operation in the JVM
because of the stacktrace information that needs to be generated, so in cases
where it is know that a null value could be returned it one should not rely on
an NPE to be catched.
> NPE silently thrown in StompSession#sendMessage
> -----------------------------------------------
>
> Key: ARTEMIS-1601
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1601
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: STOMP
> Affects Versions: 2.4.0
> Environment: Artemis 2.5.0-SNAPSHOT
> Reporter: Johan Stenberg
> Assignee: Justin Bertram
> Priority: Minor
>
> During debugging a stomp session I realized that the StompSession's send
> method does not check if looking up a subscription returns null:
> {code:java}
> StompSubscription subscription = subscriptions.get(consumer.getID());
> {code}
> This later sometimes results NPEs at:
> {code:java}
> if (subscription.getAck().equals(Stomp.Headers.Subscribe.AckModeValues.AUTO))
> {
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
