Task #2271
Updated by mhrivnak about 8 years ago
In 2.y and currently on 3.0-dev branches, branches the Exception objects are storage is stored inconsistently. It is backed by two json fields. One is for storing non-fatal exceptions, and another is for storing a single fatal exception field. When saving an exception, the exception type will give you different types of information. Here are the current behaviors: Exception -- you'll get the entire traceback as one string. It includes the Exception name and message, but it's not structured which means the API can't structure it easily either. The traceback is logged once in the logs. PulpException -- same as exception PulpCodedException -- you'll save a dictionary with the following keys: 'code', 'description', 'data', and 'sub_errors'. What you won't save is the type (besides the 'code') or message (maybe that's 'description'?) or the traceback in any way. The traceback is logged once in the logs, but regularly we have users who are not the admins and don't know where the logs are try to find that one line. Also sub_errors allows for recursive nesting. With ^ in mind here are some questions: * Do we want a dictionary in all exception cases with 'traceback' and 'message' as keys? * Should 'code' also be there but be None when not set? * Do we want to keep sub_errors and the recursive storage? * Should we structure tracebacks better or is this a client side issue?
.