Developer oriented error messages have been added as coded exceptions
A good reason not to put developer errors in the "coded exceptions" is that the coded exceptions need to be well documented and communicated to the users. As these users include our API consumers who may wish to respond to our error code, this will cause them to spend time thinking about how to handle a problem they will never experience. Let's save them the time by just raising a normal boring old Python Exception (or the subclass that makes the most sense). Also, it's probably not necessary to use gettext since working on our code already implies that developers know English enough to read/write our docblocks and comments and variable/function names ☺
We should check for this in all plugins too. We need to do this before we release 2.8.0 because some of these were introduced new in 2.8 and once we release we have to keep it.
#1 Updated by rbarlow over 5 years ago
- Checklist item Review all coded exceptions that are new in 2.8 to see if any are developer oriented. Remove them if they are. added
- Checklist item Audit all of the plugins for the same. added
- Checklist item Fix any uses of these errors to use normal Python Exceptions (pick an appropriate one for each case). added
Please register to edit this issue