[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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||||||||||
| 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. |