Currently Errors in Detectors, e.g. an un-intentional IndexError, KeyError, or ValueError, should raise a traceback.

Currently the error is formatted like an Error message raised by a Reject exception.

I *think* this is Legacy code that allowed detectors to raise these errors for some backward compatibility but this is one or two decades ago.

The offending code is in cgi/actions.py in some of the edit/create actions:

Line 843 in EditItemAction:
    except (ValueError, KeyError, IndexError, Reject) as message:
Line 890 in NewItemAction:
    except (ValueError, KeyError, IndexError, Reject) as message:
Line 1106 in RegisterAction:
    except (ValueError, KeyError, IndexError, Reject) as message:

this is raised in all cases when the called _editnodes raises an exception (which in turn calls a database action which in turn calls detectors).
In my opinion (and experience) this can only happen when a detector raises an exception. Detectors should never raise one of those exceptions (apart from Reject) in the error-free case. I think we should fix this and put it into the documentation for upgrading.

Note that somewhere else in the framework ValueError is also handled synonymous to Reject, it has to be checked if that is also legacy.

Let me know what you think, an in particular if you're using those errors for raising an error message to the user instead of using Reject for that purpose.

I'd also appreciate your experience when writing detectors that it's *very* hard to really find out what went wrong and where.

Note also that there may also be similar errors in the rest and xmlrpc APIs which should probably raise an internal server error in these cases. I would make a separate issue for those once we've decided on a course.