Question

I’m having a spot of bother here.
I’m working on a multi-tiered CAB application that uses a Web-service for authentication and a WinForms front-end.

Now, I’ve been asked to implement password expiry and have gotten the necessary details and I’ve used them to see if the user’s password has expired, only thing is, I’m having trouble pausing the login process and “redirecting” to the ChangePassword form.

What I’ve been trying is throwing a custom exception called PasswordExpiredException(inherits System.Exception and later ApplicationExcetion when that didn’t work) and calling ChangePassword.ShowDialog() in the catch. This is causing a headache because it’s doing what I’m damned well telling it to do, and throwing an unseemly exception at log-on, if the password has expired.

So, can I un-throw my exception when it’s done it’s job?
OR, should I scrap the idea and do it “properly”? Not having any clue what that might be

A basic run-through of the callstack at log on ~~>

Logon.Cs.btnOK_Click ~~> wsAuthentication.GetProvider(GetUserDBInstace(UserName))~~>
ASPNETAuthentication.Authenticate(username,password)~~>
CheckIfExipred(MembershipUser.LastPasswordChangedDate) 
~Y~> throw PasswordExpiredException; //getting it to go back all the way to the UI, opening up ChangePassword.cs, leaving me with an authenticated user who's about to change his old password
~N~> //continue login, ignoring all my hard work

Answer 1

Instead of throwing an exception, I would consider returning some sort of AuthenticationResult. It seems to me that you’re trying to use exception handling to manipulate control flow. Exceptions should be exceptional. What you’re suggesting sounds like a completely legitimate business rule.

public class AuthenticationResult {
  public bool AreCredentialsValid { get; set; }
  public bool IsAccountLocked { get; set; }
  public bool RequiresPasswordChange { get; set; }
}

You can then query the returned object to determine what to do next, instead of trying to handle an exception.