In some situations I’m not sure whether it’s better to let it crash or not. I can identify three main types of errors:
- Programmer error => let it crash
- User error (invalid form input) => handle the error through changeset validators and display an error message for user to correct
- Programmer error OR abnormal/malicious user input => ?
For the latter I’m not sure how to handle these errors. Say a form that contains a <select> element, allowing you to specify a relation; e.g. a user fills a doctor’s appointment details, and he has to select one of the possible doctor’s offices. These office IDs can’t be changed by a normal user as the <select> offers a limited set of options, but some malicious user could go into Developer Tools and change the <option> value, which will result into a DB foreign key contraint error.
For these cases, where an error might be the programmer’s fault, but also might be the user causing it (we should remember this is external untrusted data), what is best to be done?
Should I systematically use Ecto foreign_key_constraint/3 to avoid crashing the process? If so, what would you display to the user?
The disadvantage with this is that if it actually was a bug, I will miss that bug (no error log).
Should I just let it crash? Crashing has some overhead though, e.g. we want to log it. Now imagine a malicious user sending thousands of requests quickly triggering these errors. As this error is related to external data, is it really wise to let it crash? Most oftenly will be a programmer error, but what if it’s not.
