<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 08:51:52 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-265] Java driver throws a lot of undeclared/non MongoException runtime exceptions</title>
                <link>https://jira.mongodb.org/browse/JAVA-265</link>
                <project id="10006" key="JAVA">Java Driver</project>
                    <description>&lt;p&gt;The following runtime exceptions are thrown by the Java driver. &lt;/p&gt;

&lt;p&gt;They make handling database failures incredibly difficult. &lt;/p&gt;

&lt;p&gt;Essentially, the only thing the Java driver should throw are a) declared exceptions (e.g., IOException) or MongoException (or a subclass of).&lt;/p&gt;

&lt;p&gt;Let me know if you are OK with these changes and I&apos;ll modify the driver.&lt;/p&gt;

&lt;p&gt;RuntimeException&lt;br/&gt;
IllegalArgumentException&lt;br/&gt;
IllegalStateException&lt;br/&gt;
UnsupportedOperationException&lt;/p&gt;</description>
                <environment></environment>
        <key id="14504">JAVA-265</key>
            <summary>Java driver throws a lot of undeclared/non MongoException runtime exceptions</summary>
                <type id="4" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14710&amp;avatarType=issuetype">Improvement</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="rn@deftlabs.com">Ryan Nitz</reporter>
                        <labels>
                    </labels>
                <created>Thu, 3 Feb 2011 20:13:06 +0000</created>
                <updated>Mon, 25 Jul 2016 17:59:37 +0000</updated>
                            <resolved>Mon, 25 Jul 2016 17:59:37 +0000</resolved>
                                    <version>2.4</version>
                                                    <component>API</component>
                                        <votes>0</votes>
                                    <watches>1</watches>
                                                                                                                <comments>
                            <comment id="114537" author="jeff.yemin" created="Sat, 28 Apr 2012 02:31:19 +0000"  >&lt;p&gt;Looking at the current code base, the uses of IllegalArgumentException, IllegalStateException, and UnsupportedOperationException seem for the most part appropriate.  There are a quite a few RuntimeException throws that could still be replaced with a more appropriate exception.&lt;/p&gt;</comment>
                            <comment id="23327" author="auto" created="Tue, 8 Feb 2011 01:26:04 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;rgnitz&apos;, u&apos;name&apos;: u&apos;Ryan&apos;, u&apos;email&apos;: u&apos;rgnitz@gmail.com&apos;}
&lt;p&gt;Message: converted RuntimeException to BSONException - &lt;a href=&quot;https://jira.mongodb.org/browse/JAVA-265&quot; title=&quot;Java driver throws a lot of undeclared/non MongoException runtime exceptions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;JAVA-265&quot;&gt;&lt;del&gt;JAVA-265&lt;/del&gt;&lt;/a&gt;&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-java-driver/commit/6125995550c6363ba8b63e824f97f227705b749c&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-java-driver/commit/6125995550c6363ba8b63e824f97f227705b749c&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="23326" author="auto" created="Tue, 8 Feb 2011 01:26:03 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;rgnitz&apos;, u&apos;name&apos;: u&apos;Ryan&apos;, u&apos;email&apos;: u&apos;rgnitz@gmail.com&apos;}
&lt;p&gt;Message: initial load - &lt;a href=&quot;https://jira.mongodb.org/browse/JAVA-265&quot; title=&quot;Java driver throws a lot of undeclared/non MongoException runtime exceptions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;JAVA-265&quot;&gt;&lt;del&gt;JAVA-265&lt;/del&gt;&lt;/a&gt;&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-java-driver/commit/5cd12184abb57f585f2592f5f05f02528a91e5f7&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-java-driver/commit/5cd12184abb57f585f2592f5f05f02528a91e5f7&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="23321" author="keithbranton" created="Tue, 8 Feb 2011 00:14:02 +0000"  >&lt;p&gt;&amp;gt;  ppl who choose to use Java expect checked exception&lt;/p&gt;

&lt;p&gt;Not sure I agree with this statement (only been using java commercially for about 12 years though). There is plenty guidance on where unchecked exceptions are appropriate, and the platform code is full of them. i.e. &lt;a href=&quot;http://www.javapractices.com/topic/TopicAction.do?Id=129&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.javapractices.com/topic/TopicAction.do?Id=129&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I think it is completely reasonable for MongoException to be checked. Most java programmers will abstract out the data layer anyway, so the checks only really need to be done in the data layer.&lt;/p&gt;
</comment>
                            <comment id="23319" author="antoine" created="Tue, 8 Feb 2011 00:04:05 +0000"  >&lt;p&gt;Having worked with checked exceptions in all libraries I used for the past 5 years, it feels very unsafe to have unchecked exception, esp for a db driver &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/warning.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;.&lt;br/&gt;
There is no downside to checked exception as long as exceptions are well organized and thrown where it makes sense.&lt;br/&gt;
If you use an IDE you actually end up doing much less typing since it can autofill try/catch block or throws.&lt;br/&gt;
To make an exception bubble up, just adds &quot;throws&quot; to the signature.&lt;br/&gt;
Right now users have no idea what we throw and I&apos;ve just closed 2 tickets in past day where ppl got exception in places where doc didnt declare it.&lt;br/&gt;
We shouldnt rely on perfect doc to make user code safe.&lt;br/&gt;
I&apos;m trying to build some larger client app to test out driver and when you have many functions it&apos;s tough to put try/catch all around by yourself and you end up with trial and error process.&lt;br/&gt;
Client app may run well for a while but then stumbles because of missed catch block.&lt;br/&gt;
I guess there has been long lived debate on checked vs unchecked but in java world that has been settled long ago (i.e. ppl who choose to use Java expect checked exception)...&lt;/p&gt;</comment>
                            <comment id="23303" author="eliot" created="Mon, 7 Feb 2011 22:05:58 +0000"  >&lt;p&gt;That construct was probably when MongoException was typed, so the try/catch can just go.&lt;/p&gt;
</comment>
                            <comment id="23300" author="rgnitz" created="Mon, 7 Feb 2011 21:59:32 +0000"  >&lt;p&gt;Are there any other references to this outside of DBCursor.java? I agree that doesn&apos;t make sense...&lt;/p&gt;


&lt;p&gt;        try &lt;/p&gt;
{
            return _next(); 
        }
&lt;p&gt;       &lt;br/&gt;
        catch ( MongoException e )&lt;/p&gt;
{
            throw new MongoInternalException( &quot;couldn&apos;t get next element&quot; , e ); 
        }
&lt;p&gt;   &lt;/p&gt;</comment>
                            <comment id="23298" author="auto" created="Mon, 7 Feb 2011 21:58:23 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;agirbal&apos;, u&apos;name&apos;: u&apos;agirbal&apos;, u&apos;email&apos;: u&apos;antoine@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/JAVA-265&quot; title=&quot;Java driver throws a lot of undeclared/non MongoException runtime exceptions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;JAVA-265&quot;&gt;&lt;del&gt;JAVA-265&lt;/del&gt;&lt;/a&gt;: Java driver throws a lot of undeclared/non MongoException runtime exceptions&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-java-driver/commit/76e13f04f1bff54f7fa025a353b72be38bb07819&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-java-driver/commit/76e13f04f1bff54f7fa025a353b72be38bb07819&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="23294" author="rgnitz" created="Mon, 7 Feb 2011 21:55:04 +0000"  >&lt;p&gt;Remove the generic RuntimeException or all runtime exceptions? &lt;/p&gt;

&lt;p&gt;The runtime exceptions make perfect sense for people who let their exceptions bubble up to another level. You don&apos;t need those blocks unless you want to act upon a particular exception.&lt;/p&gt;

&lt;p&gt;If they are catching MongoInternalException specifically it will still catch, unless they are catch MongoException first.&lt;/p&gt;

&lt;p&gt;+1 for more error codes &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;-1 for a checked exceptions - The original driver had them and I was very happy to see them go.&lt;/p&gt;</comment>
                            <comment id="23290" author="antoine" created="Mon, 7 Feb 2011 21:47:35 +0000"  >&lt;p&gt;We have a bunch of the following around:&lt;/p&gt;

&lt;p&gt;            try &lt;/p&gt;
{
                 ...
            }
&lt;p&gt;            catch ( MongoException me )&lt;/p&gt;
{
                throw new MongoInternalException( &quot;can&apos;t do getmore&quot; , me );
            }

&lt;p&gt;It didnt really make sense before, and now even less since MongoInternalException extends MongoException.&lt;br/&gt;
Would love to get rid of these blocks in 2.5.&lt;br/&gt;
It can potentially affect some users if they were trying to catch MongoInternalException specifically.&lt;br/&gt;
But since we use Exception so loosely, and it was not documented, pretty sure everyone just does &quot;catch(Exception e)&quot;.&lt;/p&gt;

&lt;p&gt;Eventually it would be to get closer to standard db drivers:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;use MongoException to represent server or client error, with a specific error code&lt;/li&gt;
	&lt;li&gt;make MongoException &lt;em&gt;checked&lt;/em&gt; so that ppl know when things can fail.&lt;/li&gt;
	&lt;li&gt;try to remove RuntimeException as much as possible.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="23146" author="auto" created="Fri, 4 Feb 2011 22:09:36 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;rgnitz&apos;, u&apos;name&apos;: u&apos;Ryan&apos;, u&apos;email&apos;: u&apos;rgnitz@gmail.com&apos;}
&lt;p&gt;Message: changed to extend MongoException - &lt;a href=&quot;https://jira.mongodb.org/browse/JAVA-265&quot; title=&quot;Java driver throws a lot of undeclared/non MongoException runtime exceptions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;JAVA-265&quot;&gt;&lt;del&gt;JAVA-265&lt;/del&gt;&lt;/a&gt;&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-java-driver/commit/c08f9c4baf063a28917d3f77fc36caa3702ed7ca&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-java-driver/commit/c08f9c4baf063a28917d3f77fc36caa3702ed7ca&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="23136" author="eliot" created="Fri, 4 Feb 2011 20:42:25 +0000"  >&lt;p&gt;making MongoInternalException extend MongoException is fine&lt;/p&gt;</comment>
                            <comment id="23134" author="rgnitz" created="Fri, 4 Feb 2011 20:35:51 +0000"  >&lt;p&gt;Ok... some progress &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;How does everyone feel about changing MongoInternalException to extend MongoException?&lt;/p&gt;

&lt;p&gt;MongoInternalException is typically thrown if there is an IOException or if there is another problem communicating with the server.&lt;/p&gt;</comment>
                            <comment id="23096" author="eliot" created="Fri, 4 Feb 2011 02:42:45 +0000"  >&lt;p&gt;these:&lt;br/&gt;
IllegalArgumentException &lt;br/&gt;
IllegalStateException &lt;br/&gt;
UnsupportedOperationException&lt;/p&gt;

&lt;p&gt;are completely kosher in my mind and should not be changed.&lt;/p&gt;

&lt;p&gt;generic RuntimeExceptions can usually be made either one of those or IOException&lt;/p&gt;

&lt;p&gt;basically these: git grep RuntimeException src/main/ | grep throw&lt;/p&gt;

&lt;p&gt;can submit a patch to change some of those, but that&apos;s it.&lt;/p&gt;</comment>
                            <comment id="23093" author="scotthernandez" created="Fri, 4 Feb 2011 01:15:50 +0000"  >&lt;p&gt;I think you are correct that better javadocs need to be added (for specific exceptions, not generic ones) and a better exceptions hierarchy needs to be maintained.&lt;/p&gt;</comment>
                            <comment id="23091" author="keithbranton" created="Thu, 3 Feb 2011 23:40:18 +0000"  >&lt;p&gt;@Ryan, please disregard my previous comment, which I have deleted now since I notice MongoException is unchecked anyway.&lt;/p&gt;

&lt;p&gt;I&apos;m not in favor of this proposal. &lt;/p&gt;

&lt;p&gt;In your example you could simply wrap the mongo call in its own try/catch if you want to handle all exceptions from mongo separately from the exceptions in other code. That is what I do - and what I expect most users do.&lt;/p&gt;

&lt;p&gt;Guaranteeing that the java driver can&apos;t ever throw NullPointerException, ArrayIndexOutOfBoundsException, or any other RuntimeException subclasses that get thrown by platform code would be very difficult.I suppose the contents of every public method in the driver &lt;b&gt;could&lt;/b&gt; be wrapped in a try/catch, but that would be ugly and inefficient. &lt;/p&gt;

&lt;p&gt;You really can&apos;t guarantee, now and forever in the future, that no unchecked exceptions besides MongoException will ever be thrown by the driver - so this change is pointless.&lt;/p&gt;</comment>
                            <comment id="23075" author="rgnitz" created="Thu, 3 Feb 2011 22:44:12 +0000"  >&lt;p&gt;Yes... right now, most of these  runtime exceptions are not documented so it is difficult to tell when something is going to come through.&lt;/p&gt;

&lt;p&gt;It&apos;s important for people to be able to easily identify and handle persistence issues based on exception types.&lt;/p&gt;

&lt;p&gt;try &lt;/p&gt;
{

// Make a call to mongo

// Make a call to some other app/service/lib

}
&lt;p&gt; catch (MongoException m) &lt;/p&gt;
{

   // handle a mongo error - persist data to flat file

}
&lt;p&gt; catch (MongoInternalException mie) &lt;/p&gt;
{ // this should extend MongoException
 
  // handle a different mongo error - persist data to flat file

}
&lt;p&gt; catch (Throwable t) &lt;/p&gt;
{

    // You can&apos;t handle these runtime errors with WriteResult

    // handle some other mongo error, is this in my app or another library? I don&apos;t know where the error originated from and i have to handle them differently

}</comment>
                            <comment id="23071" author="scotthernandez" created="Thu, 3 Feb 2011 22:15:22 +0000"  >&lt;p&gt;So you think that a bad/illegal argument should result in a MongoException?&lt;/p&gt;

&lt;p&gt;What do you plan to do with those runtime exceptions?&lt;/p&gt;</comment>
                    </comments>
                    <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|hrga1z:</customfieldvalue>

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