@avdi writes:

```markdown
## Some questions before raising

1. Is the situation truly unexpected?
  - User input is a classic example of a case where we expect mistakes. 
2. Am I prepared to end the program?
3. Can I punt the decision up the call chain? 
  - is there any way I could allow the caller to push its own deci- sions down into my code, and maybe provide some sensible defaults? Do I want to capture and log failure instead of aborting? Am I certain this condition represents an unexpected condition, and if not, can I delegate the decision to the caller?
4. Am I throwing away valuable diagnostics? 
  - You want to preserve as much of that information as possible—if nothing else, so that you can get to the bottom of the failure more easily. See if you can enable the code to continue normally while still noting the fact that there was a problem, using some kind of sideband. Or, make sure that any exceptions raised have all of the relevant diagnostic data attached to them before they are raised.
5. Would continuing result in a less informative exception?
  - Sometimes failing to raise an exception just results in things going wrong in less easy-to-diagnose ways down the road. In cases like this, it’s better to raise earlier than later. This is often the case with precondition assertions

Of the three failure types: user error, logic error, and transient error, this would be a logic error
```