Opened 7 years ago

Closed 5 years ago

Last modified 3 years ago

#6842 closed (fixed)

Documentation: Document Django exceptions

Reported by: Ashish Gupta <neerashish@…> Owned by: varikin
Component: Documentation Version: master
Severity: Keywords: model
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: UI/UX:

Description

Using Django, many people are going to be writing web applications ( like salesforce.com for example) as opposed to mainly content/publishing sites ( example wapo and curse) and they will need to know the list of exceptions.

Please document exceptions django throws. Specially those thrown/raised by model methods.
I want to catch those exceptions and display appropriate custom message to my users (not the default 404).

From: Malcolm Tredinnick <malc...@…>
Date: Fri, 21 Mar 2008 05:44:56 +1100
Local: Thurs, Mar 20 2008 11:44 am
Subject: Re: Django Exception handling
Reply | Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author

There's a list of most of Django's exceptions in
django/core/exceptions.py. In addition to that, you can get database
exceptions (DatabaseErrror and IntegrityError are two we push into the
Django namespace, but all errors from the DB API are possible), plus a
few internal Python exception types. Search for 'raise' in
django/db/models/base.py, for example. In fact, search for 'raise' in
django/db/models/ and subdirectories to see the full set of
possibilities there.

Regards,
Malcolm

Attachments (3)

r8472.diff (1.7 KB) - added by varikin 7 years ago.
r8643.diff (3.4 KB) - added by varikin 7 years ago.
6842.diff (5.4 KB) - added by timo 5 years ago.
small improvements to existing patch

Download all attachments as: .zip

Change History (15)

comment:1 Changed 7 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

I have a better plan. Since you need this information and are about to pull it out for your own use, write it up as you go and submit a docs patch. That way everybody will benefit from your work.

comment:2 Changed 7 years ago by neerashish@…

sounds good. I will take it.

Changed 7 years ago by varikin

comment:3 Changed 7 years ago by varikin

  • Has patch set
  • Owner changed from nobody to varikin
  • Patch needs improvement set

I have started a doc for this since I needed info on the exceptions. I haven' finished it, far from it, but I would like someone to take a look at it and see if I am heading in the right direction.

Changed 7 years ago by varikin

comment:4 Changed 7 years ago by varikin

I have a fairly complete patch I think. I am sure there is still work to be done. I don't really know all the use cases of each exception, but I did my best.

One thing that needs to be fixed is I was linking to the the get() method in the db-api docs, but I think i had that link wrong, and then the docs refactor landed and it is now definitely wrong.

Also, I don't really know what a suspicious operation is or what "middleware not used" means. I just rewrote what was in exceptions.py.

I know this is far from perfect but if I waited til it was perfect before submitting, I would never submit it:)

Changed 5 years ago by timo

small improvements to existing patch

comment:5 Changed 5 years ago by mrmonkington

I think the development debug error pages are also a really great source of documentation and it would be incredibly useful to Django noobs like me if these could just show which module an exception was defined in (and not just which file raised it).

comment:6 Changed 5 years ago by Rupe

  • milestone set to 1.2

This looks like it's good to go.

comment:7 follow-up: Changed 5 years ago by ericholscher

Not sure why this patch is touching the Queryset.get bits, that feels like it should be a different ticket. It applies cleanly to trunk, and feels like useful information to include. I know that a lot of people I've talked to didn't know about raising ImproperlyConfigured and the like.

The docs should probably also mention that these exceptions can be raised by user code, and not just Django, and the appropriate situations there (though it should match/jive with how Django uses them).

comment:8 Changed 5 years ago by Alex

Some of these exceptions, MiddleWareNotInUse is only ever raised from usre code.

comment:9 in reply to: ↑ 7 Changed 5 years ago by ramiro

Replying to ericholscher:

Not sure why this patch is touching the Queryset.get bits, that feels like it should be a different ticket.

It is adding meta data mark up so cross-linking from inside the exception description paragraphs is saner. Anyway that is being attacked in a more complete way in #12997

comment:10 Changed 5 years ago by russellm

  • Resolution set to fixed
  • Status changed from new to closed

(In [13180]) Fixed #6842 -- Added reference documentation on Django's exceptions. Thanks to timo for the patch.

comment:11 Changed 5 years ago by russellm

(In [13182]) [1.1.X] Fixed #6842 -- Added reference documentation on Django's exceptions. Thanks to timo for the patch.

Backport of r13180 from trunk.

comment:12 Changed 3 years ago by jacob

  • milestone 1.2 deleted

Milestone 1.2 deleted

Note: See TracTickets for help on using tickets.
Back to Top