   [.net] Exceptions: Am I doing it right?
  I developed a poker application recently, and in certain parts of it I use exceptions to alert some problems. Here are some excerpts of what I use them for:First my actual exception classes:public class JoinGameException : ApplicationException    {   public enum Reason   {  NotEnoughMoney, GameFull, NotAcceptingPlayers, PlayerAlreadyExists   }   public Reason reason;   public Player player;   public JoinGameException(Reason reason, Player player, string message) : base(message)   {  this.reason = reason;  this.player = player;   }    }    public class BidException : ApplicationException    {   public enum Reason   {  NotEnoughMoney, NotAcceptingBids, NotCurrentlyBetting, UserDoesntExist   }   public Reason reason;   public Player player;   public BidException(Reason reason, Player player, string message)  : base(message)   {  this.reason = reason;  this.player = player;   }    }And now where I use them:private int PlaceBet(Player player, int amount)   {  if (currentState != GameStates.Bidding)  { throw new BidException(BidException.Reason.NotAcceptingBids, player, player + " is unable to place a bet because the game is not accepting bets");  }  if (!playerList.Contains(player))  { throw new BidException(BidException.Reason.UserDoesntExist, player, player + " is unable to place a bid because he is not in the game");  }  if (!currentBetter.Equals(player))  { throw new BidException(BidException.Reason.NotCurrentlyBetting, player, player + " is unable to place the bet because it is not his turn");  }  if (!player.TakeMoney(amount))  { throw new BidException(BidException.Reason.NotEnoughMoney, player, player + " is unable to place the bet because he does not have enough money");  }bla bla bla...}Andpublic void AddPlayer(Player player)   {  if (currentState != GameStates.WaitingForPlayers)  { throw new JoinGameException(JoinGameException.Reason.NotAcceptingPlayers, player, player + " is unable to join because game is not accepting players");  }  if (playerList.Count &gt;= MAXPLAYERS)  { throw new JoinGameException(JoinGameException.Reason.GameFull, player, player + " is unable to join because the game is full");  }  if (playerList.Contains(player))  { throw new JoinGameException(JoinGameException.Reason.PlayerAlreadyExists, player, player + " is unable to join because he is already in the game");  }  if (!player.TakeMoney(ante))  { throw new JoinGameException(JoinGameException.Reason.NotEnoughMoney, player, player + " is unable to join game because he does not have enough money to cover the ante");  }...My question is, are these decent uses of exceptions? One of the things said about exceptions is only to use them in "exceptional" cases, but a lot of these are pretty common. However, the only other option I can think of is to use return values, but I'm not sure if that would be the better solution either. Can anyone give me some feedback on how I am going about this? ThanksEdit: code tags didn't work gotta fix   
  I'd check preconditions and act approbiatly. The exceptions you throw can stay in but they'd only occur in exceptional cases (such as when, you made a coding error with your preconditions).   ;  The only problem I see with that is then I can't signal the calling code that a problem occurred (might be able to get away with return codes on the join game part but not the bid exception). Not sure what you mean by coding errors in the preconditions, because that makes me think of a compiler error.   ;  Exceptions are not used for standard application control.All of those "exceptions" you listed are what you would expect on a normal day to day running of the application.Exceptions are suppose to be used for "exceptions", something that is not normally suppose to happen (missing file, not able to write to a DB, etc.)Using exceptions carry a lot more overhead then standard application control statements.theTroll   ;  Yea that's sort of what I was thinking, but the problem is what do I replace it with? The PlaceBet function returns the amount of chips that were actually used, so I'm not sure if using a return type here would be possible, but maybe there is another way?   ;  All of these exceptions fall under one of two categories it appears:1) Display a message and do nothing2) Not allow the action that you're making an exception to occur in the first place by checking first.Exceptions should only be thrown when you have no other option.   ;  I also think the use of exceptions in the way your are doing it is an abuse of the exceptions (and a possibly performance problem.)You talk about the PlaceBet returning the amount of chips used.  And I think this is what it should return.  But, whoever calls PlaceBet should check, before making the call, if it is possible to place the bet (i.e., checking, however appropriate, the currentState before the call to PlaceBet.)This way the "be in an state allowed to place a bet" is a pre-condition of PlaceBet that the caller must check before calling PlaceBet.  If someone calls PlaceBet in a currentState different of GameStates.Bidding this is a pre-condition violation and anything can happen (i.e., is unspecified what the function will return.)  Of course, since we are all humans and can make errors, add an assert or equivalent that actually checks that the currentState is GameStates.Bidding inside PlaceBet so you can catch such errors while developing.   ;  I think your exceptions are mostly fine, but you should avoid using them for flow control.  So you should have complementary methods like bool CanPlaceBet(Player player, int amount) and bool CanAddPlayer, which if they returns false, then it's guaranteed that the complementary function will throw an exception.  This way you can avoid using exceptions for flow control by checking, say, the CanPlaceBet function before calling PlaceBet, but you keep the exceptions to catch bugs if you forget to call CanPlaceBet somewhere.Also, does player.TakeMoney actually reduce the player's bankroll?  I would avoid this sort of thing because it makes your exception checking code at the beginning of the function have a side-effect.  You should have something like if (player.Money < bet) throw exceptionplayer.Money -= bet;Then have the Money setter throw an exception if the value is less than zero.  It will never get there in the above code, but the code is safe from abusing the Money property.   ;  Ok so from what I am reading, it should pretty much be the caller's responsibility in founding out the cause of a failed bet by checking the preconditions and whatnot.I was using the exceptions mainly as a way to inform the caller of the exact reason why it failed, instead of just returning some error code and letting the caller sort it out (hopefully it won't make it this far since the caller will check the preconditions before hand).Anyway, thank you all for the help.   ;  Reading over your code, I would suggest you implement a state machine for what you're trying to do.Exceptions are generally reserved for error conditions from which recovery cannot be immediately acccomplished. As an example: attempting to connect to a login server, and having the connection rejected should throw an exception (and does). Opening a non-existant file can throw an exception, and it should because it doesn't know what to do from there, but your code might (which is why you would catch it). Nothing you've shown in your source though is "exceptional" in nature.Now, if you received a strange or unexpected packet, then you might throw an exception so that higher level code could trap it and decide what to do.   