[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: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||
| Description |
|
I would like to suggest wrapping internal I/O exceptions in a custom exception (i.e. MongoCommunicationException).
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 ] |
|
|
| 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 ] |
|
|
| 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. |
| 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: |