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)

[Beetle_B]

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.

[Beetle_B]

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.

[Beetle_B]

Changed the summary...

[Jacob]

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

[Beetle_B]

"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?

[Julian Bez]

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.

[Beetle_B]

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

[Julian Bez]

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.

[(none)]

Milestone post-1.0 deleted