Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#8772 closed (wontfix)

When a get_object_or_404 returns a 404, it'd be nice if it would return which query didn't provide an object (when DEBUG=True)

Reported by: Beetle_B Owned by: nobody
Component: Uncategorized Version: dev
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I recently had an error in a query in a context processor. When I tried to go to a certain page, I got the error:

"No CollabProject matches the given query".

And practically no other information. No trackbacks or anything. No indication of which file the error was in. Just that message and a 404.

I kept checking and couldn't find any error in my view. I even confirmed that the view executed to the end.

It was only by chance that I discovered the error in the context processor.

Isn't there a way to have it such that if the error occurs in a context processor, it can point to the line in the context processor that had the bad query?

BTW, by bad query I mean a valid query that doesn't return any objects in the database.

I suspect this may be a problem with such a query in a middleware, but did not experiment.

Change History (8)

comment:1 by Beetle_B, 16 years ago

In retrospect, I realized it wasn't an error, as I was using a get_object_or_404. So the function was doing exactly what it should - returning a 404.

Nevertheless, it would be nice if when this happens, it could return the location of the query that did not find any object (when DEBUG=True). It's help in debugging.

comment:2 by Beetle_B, 16 years ago

Summary: Errors in queries in context processors give a very unhelpful error page.When a get_object_or_404 returns a 404, it'd be nice if it would return which query didn't provide an object (when DEBUG=True)

Changed the summary...

comment:3 by Jacob, 16 years ago

Resolution: wontfix
Status: newclosed

get_object_or_404 already gives you enough info to debug it; if you want more info do a try/except yourself.

comment:4 by Beetle_B, 16 years ago

"get_object_or_404 already gives you enough info to debug it; if you want more info do a try/except yourself."

It doesn't tell me which query is the one throwing the 404, or even which file that query resides in.

Or am I missing something?

comment:5 by Julian Bez, 16 years ago

milestone: post-1.0

Since the debug-404 page is for, well, debugging, it could certainly be useful to have more info when get_object_or_404 raises the 404.

comment:6 by Beetle_B, 16 years ago

"Since the debug-404 page is for, well, debugging, it could certainly be useful to have more info when get_object_or_404 raises the 404."

So...does that mean you hope to change the behavior after 1.0?

I ask only because you the status of the ticket is still "wontfix"...

comment:7 by Julian Bez, 16 years ago

It is wontfix because a core dev decided so. After thinking about it, 404s are raised almost always intentionally, so if you don't know why it was raised you just don't know your code.

comment:8 by (none), 16 years ago

milestone: post-1.0

Milestone post-1.0 deleted

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