For a Django-Server I use several custom Error-Codes, error-titles and descriptions, possibly other fields might follow.

I'm using right now a basic global dictionary.

errordict = {'512':
        'errorno': 512,
        'errordescr': "Database Down",
        'toDo': "Restart the database, Server: "+serveradr
'513' : ....

And in the code something like:

def handleError(s_err):
   logging.error("Error "+s_err+" occurred: "+curerr['errordescr'])

The usage looks like this:

   except NoSuchEntryEx as nsee:
      return HttpResponse(render_to_string('error.html', {                
                'errorno':  s_err,
                'errordescr': mark_safe(str(nsee)
                                        + const.OUTPUT_NEWLINE),                
                'toDo': errordict[s_err]['toDo']

I'm not happy with that and would rather define its own class - which would from the current perspective would just consist of this single, growing dict-object, which does not seem a great idea either.

It's of course a constant, every change there is hard-coded.

  • \$\begingroup\$ @Peilonrayz - provided more information, but it's just reading the dict, nothing else. It has a name, but there's nothing interesting about it. The dict grows and I'd like to improve how I access the codes and descriptions. \$\endgroup\$
    – Qohelet
    Commented Feb 17, 2021 at 13:45
  • 1
    \$\begingroup\$ Thank you. I don't really see the problem, your code looks fine. Is there more code you could show? For example you've shown how 513 is used, could you show how 512 is used? What do the functions that call the usage look like? The more code you provide the more we can see the problem. \$\endgroup\$
    – Peilonrayz
    Commented Feb 17, 2021 at 13:50
  • \$\begingroup\$ @Peilonrayz - I added the usage, as said it's nothing out of the ordinary. But the dict keeps growing and I want to keep it out of the file for clearer administration and separation. When I move it I'd like to put some thought into having a better data-structure and be open for possible changes. I have searched around, but this seems to be the only solution. Can it be? \$\endgroup\$
    – Qohelet
    Commented Feb 17, 2021 at 14:00
  • \$\begingroup\$ Sounds like you should use Pythons exception handling. This allows you to add your own exceptions... \$\endgroup\$
    – agtoever
    Commented Feb 27, 2021 at 21:48
  • \$\begingroup\$ @agtoever - I do that heavily: NoSuchEntryEx - in this specific case there is just not much left to do for me on the server \$\endgroup\$
    – Qohelet
    Commented Mar 8, 2021 at 17:00


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.