Documentation: Document Django exceptions

[Ashish Gupta <neerashish@…>]

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

[Malcolm Tredinnick]

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.

[neerashish@…]

sounds good. I will take it.

[John Shimek]

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.

[John Shimek]

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:)

[Tim Graham]

small improvements to existing patch

[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).

[Joshua Russo]

This looks like it's good to go.

[Eric Holscher]

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).

[Alex Gaynor]

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

[Ramiro Morales]

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

[Russell Keith-Magee]

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

[Russell Keith-Magee]

(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.

[Jacob]

Milestone 1.2 deleted