[CSHARP-153] Wrapping internal communication exceptions Created: 20/Jan/11  Updated: 14/May/14  Resolved: 24/May/12

Status: Closed
Project: C# Driver
Component/s: Feature Request
Affects Version/s: 1.0
Fix Version/s: 2.0

Type: Improvement Priority: Major - P3
Reporter: Aristarkh Zagorodnikov Assignee: Craig Wilson
Resolution: Duplicate Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File CS-153.patch     Text File MongoConnection.cs.patch    
Issue Links:
Related
related to CSHARP-155 Support for error codes in command re... Closed
related to CSHARP-393 MongoConnectionPool should throw some... Closed
is related to CSHARP-474 Review all exceptions thrown by the C... Closed
Backwards Compatibility: Minor Change

 Description   

I would like to suggest wrapping internal I/O exceptions in a custom exception (i.e. MongoCommunicationException).
Imagine the following scenario:

  • I connect to a replica set and begin perform queries
  • Suddenly, the server I was querying goes down and the NetworkStream.Read() throws IOException, which gets to my code
  • I have no knowledge which exceptions could be thrown from the below code and if I should retry the operation (catching all types of exceptions, especially in a hosted environment is very risky, think ThreadAbortException for example).

But, if the connection management layer of the driver would wrap all I/O-related exceptions into one type of exceptions (a new one, MongoCommunicationException or even the existing one MongoConnectionException), the driver user would instantly know that there was a problem with MongoDB connection, not some fluke in his code, and retrying/reporting failure becomes much easier.



 Comments   
Comment by Craig Wilson [ 08/Sep/12 ]

CSHARP-474 will handle this.

Comment by Craig Wilson [ 24/May/12 ]

We will be reviewing all exceptions as part of the 2.0 release as making changes like this are backwards breaking.

Comment by Robert Stam [ 02/Apr/12 ]

The coding is relatively trivial. The difficult part is analyzing all the places an exception might be thrown and deciding if to wrap the exceptions, which exceptions to wrap, and what to wrap them with.

Comment by Asoka Sampath Edussooriya [ 02/Apr/12 ]

is there a way to help you guys by coding on this project ?

Comment by Robert Stam [ 15/Mar/12 ]

CSHARP-152, CSHARP-155 and CSHARP-393 are all related in that they all are about how errors are presented to the caller (what exception type, what error message, are there any codes or additional data available to facilitate programmatic interpretation of the exception, etc...). These are being pushed to at least 1.5 to allow time for discussions to occur with other driver writers with the goal of presenting a mostly unified solution.

Comment by Aristarkh Zagorodnikov [ 24/Jun/11 ]

In our environment (I can't speak for everyone of course), the only exceptions we occur when the primary goes away is IOException that originates in the already wrapped code (hence the 2-line patch, we never saw any other exceptions that needed wrapping). While I believe there are other places that might need additional attention, I think they might be addressed in one of a future patches, that will further reduce the number of distinct exceptions that might be thrown from the inner workings of the driver. On the other hand, "driver experience" can be improved right now by getting the wrapper in MongoConnection.HandleException and/or wrapping other places that are mentioned in Miguel's patch.
P.S. I don't think the MongoAuthenticationException and other non-transient exceptions should be wrapped since they already have a defined meaning that is readily known to the client, so I think making a catch-all block, blindly converting any exception to a MongoConnectionException won't do any good, since if there's an error in the driver code (for example there's an ArgumentException or an NullReferenceException thrown in some rare cases when parsing server response), it should not be handled like MongoConnectionException (this would do more harm than good), thus the proposed IOException as the main candidate for conversion.

Comment by Miguel Pilar [ 24/Jun/11 ]

I think that is not what the immediate concern is, at least for me the main issue are the exceptions that are already being caught, processed and then rethrown. I think those main sticking points can be addressed quickly.

Comment by Robert Stam [ 24/Jun/11 ]

It's OK to pester...

I didn't have time to get this into 1.1.

The difficulty is that it's not just one place that should be wrapped. I probably need to examine the whole code base to find all the places where lower level exceptions should be wrapped, and that's a big job.

Comment by Aristarkh Zagorodnikov [ 24/Jun/11 ]

Sorry for pestering, any planned progress on this?

Comment by Aristarkh Zagorodnikov [ 30/Apr/11 ]

I would like to propose an even simple exception handling mechanism that would have very low impact and would fit into existing connection exception handling pattern – just extend HandleException error checks.

Comment by Miguel Pilar [ 12/Apr/11 ]

Quick patch wrapping communication exceptions that are being re-thrown with MongoConnectionException and a generic message.

Comment by Aristarkh Zagorodnikov [ 31/Mar/11 ]

Example exception:

System.IO.IOException: Unable to read data from the transport connection. ---> System.Net.Sockets.SocketException:
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
— End of inner exception stack trace —
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at MongoDB.Bson.IO.BsonBuffer.LoadFrom(Stream stream, Int32 count) in C:\work\10gen\mongodb\mongo-csharp-driver\Bson\IO\BsonBuffer.cs:line 272
at MongoDB.Bson.IO.BsonBuffer.LoadFrom(Stream stream) in C:\work\10gen\mongodb\mongo-csharp-driver\Bson\IO\BsonBuffer.cs:line 248
at MongoDB.Driver.Internal.MongoConnection.ReceiveMessage[TDocument](MongoServer server) in C:\work\10gen\mongodb\mongo-csharp-driver\Driver\Internal\MongoConnection.cs:line 338
at MongoDB.Driver.Internal.MongoCursorEnumerator`1.GetReply(MongoRequestMessage message) in C:\work\10gen\mongodb\mongo-csharp-driver\Driver\Internal\MongoCursorEnumerator.cs:line 202
at MongoDB.Driver.Internal.MongoCursorEnumerator`1.GetMore() in C:\work\10gen\mongodb\mongo-csharp-driver\Driver\Internal\MongoCursorEnumerator.cs:line 194
at MongoDB.Driver.Internal.MongoCursorEnumerator`1.MoveNext() in C:\work\10gen\mongodb\mongo-csharp-driver\Driver\Internal\MongoCursorEnumerator.cs:line 103

Generated at Wed Feb 07 21:35:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.