[CSHARP-207] SafeMode should allow for errors to be handled externally without throwing an exception Created: 20/Apr/11 Updated: 02/Apr/15 Resolved: 25/Apr/11 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Aristarkh Zagorodnikov | Assignee: | Robert Stam |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Description |
|
Currently, enabling safe mode (SafeMode.Enabled == true) leads to MongoSafeModeException to be thrown if the command failed. While it's a fine thing to do generally, throwing the exception if the error is expected (think unique constraint violations for example) isn't a good idea in the terms of performance (in .NET under Windows, throwing an exception takes a lot of time, hurts cache, etc.). |
| Comments |
| Comment by Robert Stam [ 25/Apr/11 ] |
|
Works as designed. |
| Comment by Robert Stam [ 20/Apr/11 ] |
|
Thanks for your input. I didn't feel like you were wasting my time at all! |
| Comment by Aristarkh Zagorodnikov [ 20/Apr/11 ] |
|
While I think that described design guidelines are a bit off the reality (no offense intended, exceptions do affect performance negatively when failures are often and expected), the argument about exception overhead being negligible with the network overhead looks as a key one to me, I didn't think about that. I think you can close this case based off the last argument, and please excuse me for wasting your time on this. And yes, I might reconsider creating that nonunique data in the first place =) |
| Comment by Robert Stam [ 20/Apr/11 ] |
|
I don't think mixing error models is a good idea. There are a lot of good exception throwing design guidelines at: http://blogs.msdn.com/b/kcwalina/archive/2005/03/16/396787.aspx (by the way, Krzysztof Cwalina and Brad Abrams's book is excellent also: Framework Design Guidelines). A couple of quotes relevant to this suggestion:
Regarding the particular case of unique constraints: if you are regularly encountering violations of this constraint there is probably something wrong with the design. Duplicate _id values on Insert are either hard errors or should have been an Update with Upsert. Duplicate values on other fields should be avoided by not creating data that violates the constraints in the first place. A final note regarding overhead: keep in mind that an exception will only be thrown after a network round trip, and any overhead involved in throwing an exception will be minimal compared to a network round trip. |