<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 08:56:24 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[JAVA-2129] Exception in callback is catched by async driver</title>
                <link>https://jira.mongodb.org/browse/JAVA-2129</link>
                <project id="10006" key="JAVA">Java Driver</project>
                    <description>&lt;p&gt;Errors inside the SingleResultCallback are catched by the mongoDB async driver. For example, if your throwable parameter is null and you access it, you won&apos;t get an exception because the driver is catching the null pointer exception. For debugging this is not ideal. The Exception should be delegated to the developers scope.&lt;/p&gt;</description>
                <environment></environment>
        <key id="268773">JAVA-2129</key>
            <summary>Exception in callback is catched by async driver</summary>
                <type id="3" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14718&amp;avatarType=issuetype">Task</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="9">Done</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="ChampS">Ben [X]</reporter>
                        <labels>
                    </labels>
                <created>Mon, 29 Feb 2016 16:59:00 +0000</created>
                <updated>Wed, 11 Sep 2019 19:09:15 +0000</updated>
                            <resolved>Thu, 28 Apr 2016 15:40:55 +0000</resolved>
                                    <version>3.2.2</version>
                                                    <component>Async</component>
                    <component>Error Handling</component>
                                        <votes>0</votes>
                                    <watches>2</watches>
                                                                                                                <comments>
                            <comment id="1249261" author="ross@10gen.com" created="Thu, 28 Apr 2016 15:40:55 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.mongodb.org/browse/JAVA-2177&quot; title=&quot;Ensure Loggers are past to ErrorHandlingCallbacks&quot; class=&quot;issue-link&quot; data-issue-key=&quot;JAVA-2177&quot;&gt;&lt;del&gt;JAVA-2177&lt;/del&gt;&lt;/a&gt; should ensure that there is always a logger to report the error to and will be available in the 3.3.0 release.&lt;/p&gt;</comment>
                            <comment id="1239789" author="champs" created="Tue, 19 Apr 2016 11:14:07 +0000"  >&lt;p&gt;mh I understand, that is really complicated. But a  compromise would be show the logged error in admin web panel or send an email to a configured email address. I understand that it&apos;s not possible to let programmers handle exceptions inside of their callbacks. But an active notification that something went wrong would probably help.&lt;/p&gt;

&lt;p&gt;mh another idea is, to create a file listener, that listens to an &quot;callback error&quot; file. If something goes wrong, the error is written to that file and the main thread error listener would recognize it. But this solution sounds a little bit hacky.&lt;/p&gt;</comment>
                            <comment id="1239143" author="ross@10gen.com" created="Mon, 18 Apr 2016 18:58:56 +0000"  >&lt;p&gt;Hi @ChampS,&lt;/p&gt;

&lt;p&gt;I fully understand it is a challenge and would like to be able to provide a simpler answer, if you have any ideas it would be good to hear them. The only way the driver can signal the users thread of the result of an operation is via the user provided callback, and its part of the contract that the provided callback must not throw an error. The reason for this is mentioned in my initial comment - the callback is executed on a different thread so it wouldn&apos;t be visible to the end user. The reason we catch and log thrown errors from the provided callback is because the alternative would be throwing the error on a connection pool thread and this would eventually poison the pool. &lt;/p&gt;

&lt;p&gt;If you want your developers to handle errors programmatically then you could, either use try catch blocks in the callback or DRY that logic up and write your own form of an &lt;a href=&quot;https://github.com/mongodb/mongo-java-driver/blob/r3.2.2/driver-core/src/main/com/mongodb/internal/async/ErrorHandlingResultCallback.java#L29-L61&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;ErrorHandlingCallback&lt;/a&gt; implementation and wrap provided callbacks - as you can see from the driver implementation it doesn&apos;t require much code. The other alternative would be writing defensive callbacks where any values from &lt;tt&gt;document.get&lt;/tt&gt; are null checked before preceding and testing to ensure no errors are thrown.&lt;/p&gt;

&lt;p&gt;Regarding Logging, Information on the configuration can be found here: &lt;a href=&quot;http://mongodb.github.io/mongo-java-driver/3.2/driver-async/reference/management/logging/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;Logging Documentation&lt;/a&gt;.  I would expect WARN level log messages to be defaulted to on. &lt;/p&gt;

&lt;p&gt;I hope that clarifies the reasoning why the driver can&apos;t throw errors generated from user provided callbacks.&lt;/p&gt;

&lt;p&gt;Ross&lt;/p&gt;</comment>
                            <comment id="1238492" author="champs" created="Mon, 18 Apr 2016 13:05:50 +0000"  >&lt;p&gt;Question: Is the default configuration to ignore these errors?&lt;/p&gt;

&lt;p&gt;Logging these errors is ok, but imho not enough. As an developer it&apos;s very problematically to recognize an error in this scenario. Most people look into log files if they notice an error or wrong behavior. Without an exception in their callback,  mostly they won&apos;t notice. In worst case they will recognize an error when it&apos;s too late, because data is missing or something. For example they show monthly aggregated data in their gui but at the end of the month there is no data. This could be prevented at the beginning of the month, if they had recognized the error or handled it programmatically. &lt;/p&gt;

&lt;p&gt;That&apos;s another Point, you take away the possibility to handle errors programmatically by the developer. They have to look into the log file and solve the problem manually.&lt;/p&gt;</comment>
                            <comment id="1238317" author="ross@10gen.com" created="Mon, 18 Apr 2016 07:42:34 +0000"  >&lt;p&gt;Just to clarify, we do log any errors that occur in this scenario.  So depending on your application logging configuration these errors maybe be printed to stdout or logged to a file or ignored (not wise).&lt;/p&gt;</comment>
                            <comment id="1190225" author="champs" created="Wed, 2 Mar 2016 13:01:09 +0000"  >&lt;p&gt;If the user itself does not handle exceptions in his callback, the expectable behavior is imho print the stacktrace. Catch the exception inside the driver and hide it from the user, just complicates the debugging process I think.&lt;/p&gt;</comment>
                            <comment id="1188140" author="ross@10gen.com" created="Mon, 29 Feb 2016 20:05:55 +0000"  >&lt;p&gt;This is &quot;as designed&quot;. The context that is running the actual code is not the same as the one passing the callback to the function.  Another thread will execute the user provided callback once the command or query has finished, either successfully or by throwing an error.  &lt;/p&gt;

&lt;p&gt;The difficulty comes if the user callback itself generates an error - who can handle the error?  Unfortunately, there is no callback available  to tell the user that the error has happened. Because the provided callback itself errors!&lt;/p&gt;

&lt;p&gt;We handle this Internally by wrapping callbacks in an &lt;tt&gt;ErrorHandlingResultCallback&lt;/tt&gt; which catches the error and then logs the error. This is a method of last resort as there is no other way to let the user know about the error.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="282517">JAVA-2177</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hsivwf:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            </customfields>
    </item>
</channel>
</rss>