[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.).
I propose a new flag to be added to SafeMode – SafeMode.Permissive. It should default to false, cannot be set to true unless SafeMode.Enabled is also true (like SafeMode.W can't be set to nonzero value while SafeMode.Enabled isn't true), and the checks that lead to an exception to be thrown inside the MongoConnection.SendMessage() method should only be done if SafeMode.Permissive is false.
The proposed solution completely preserves backwards compatibility and greatly aids if one wants to examine and handle MongoDB error responses on his own without incurring the performance penalty of catching exceptions while a simple error code check would suffice.



 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:

  • Do not return error codes. Exceptions are the primary means of reporting errors
  • Do not have public members that can either throw or not based on some option
  • Do not use error codes because of concerns that exceptions might affect performance negatively

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.

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