I blogged recently about what I saw as flaws in the design of the ASP.NET MembershipProvider API. Robert McLaws responded in comments:
Mike, your argument is incorrect. Microsoft development guidelines clearly state that exceptions are expensive and should be avoided whenever possible. The Provider Model was not designed to make the decision for you on whether or not something is exception-worthy, that is why this specific function returns a boolean. If the exception is going to be thrown, it should happen either inside your custom Provider (which is again not recommended because they are expensive) or from your method call.
I stand by my original argument, but perhaps I need to elaborate on my position. I am well aware of the cost of exceptions, and I agree that one should be cognizant of the overhead. Still, I feel strongly that as long as exceptions are not abused (for flow control, for example), they ought to be the preferred way to handle “exceptional” events in code. Doing otherwise, just because Structured Exceptions incur overhead, but without having a measured reason to do so, is a clear example of Premature Optimization.
Back to the MembershipProvider API. Robert stipulates that the designers of the API did not want to force the SEH paradigm onto its users and thus chose the approach where function calls return boolean “success” flags. On first glance this argument has merit, so lets assume Robert is right in his assumption. I still have two problems with the API.
First of all, the ChangePassword call is not something I would expect to be executed with such frequency that the failure rate would be high enough for the Exception handling overhead to matter regardless of how busy your web site is!!! So, either the method declaration was chosen to match other method(s) that do match this pattern (which one(s)?!?); or we are back to premature optimization; or Microsoft decided that Structured Exceptions are not appropriate for web development in general. That last one I just don't believe.
The other problem I have with the ChangePassword definition is that even if we were to assume that Robert is correct, that Microsoft measured and concluded that exceptions caused too much overhead for MembershipProvider scenarios, that using them was just not appropriate here, I still think they need to rethink the naming convention. At the very least ChangePassword and its ilk should become TryChangePassword to match a similar convention adapted for type convertion for these, presumably same considerations.