[CSHARP-474] Review all exceptions thrown by the C# driver Created: 23/May/12  Updated: 11/Oct/18  Resolved: 11/Oct/18

Status: Closed
Project: C# Driver
Component/s: Error Handling
Affects Version/s: 1.4.2
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Robert Stam Assignee: Unassigned
Resolution: Won't Fix Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by CSHARP-691 UpdateBuilder.Set throws InvalidOpera... Closed
Duplicate
duplicates CSHARP-506 Throw better exception when comparing... Closed
Related
related to CSHARP-534 MongoServerInstance.AcquireConnection... Closed
related to CSHARP-155 Support for error codes in command re... Closed
related to CSHARP-153 Wrapping internal communication excep... Closed
related to CSHARP-393 MongoConnectionPool should throw some... Closed
related to CSHARP-473 Unexpected InvalidOperationException ... Closed
related to CSHARP-463 Unexpected and not documented excepti... Closed
is related to CSHARP-689 Incorrect error message from ObjectId... Closed
Case:
Backwards Compatibility: Major Change

 Description   

In some cases the C# driver is not throwing the most appropriate exception. This task is a high level one to review all the exceptions being thrown by the C# driver to verify that the correct type is being thrown and that the error message is appropriate.

Several other JIRAs that refer to specific instances of exceptions that are being questioned are linked to this JIRA.

Note that changing the type of an exception thrown is a breaking change because code written to catch the exception will no longer catch it when the type changes. Changing the error message is also potentially a breaking change because sometimes user code inspects the text of the error message.



 Comments   
Comment by Sleeper Smith [ 08/Jan/13 ]

"Note that changing the type of an exception thrown is a breaking change because code written to catch the exception will no longer catch it when the type changes. Changing the error message is also potentially a breaking change because sometimes user code inspects the text of the error message."

Maybe create a new type of exception that inherit from the original exception, and add in message "obsolete, this exception will not be caught using xxx type"?

As for message inspection, shouldn't have done that in the first place. Ignore them imo.

Comment by Alexander Nagy [ 27/Jul/12 ]

I've noticed several cases of this too, such as throwing FileFormatException which seems wrong as it is designed to refer to a specific entity (i.e. file or url, note the constructor variants) and in the BSON code no specific files are being dealt with. Likely the intended exception is either InvalidDataException with in some rare cases EndOfStreamException. Also there were spots where it seemed like a SerializationException should be thrown instead (in the non-Bson\IO code) - preferably a class derived from SerializationException if SerializationException is thrown.

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