Improved Error Reporting in Django - GSoC

[Sachin Gupta]

Hi,

My name is Sachin Gupta and I am student of Indian Institute of Technology Roorkee, in my final year of undergraduate course in Computer Science. I have been developing a project entirely based on Django for the last 4 months. Here is the link and it has been absolutely fun using Django. But I have had my share of trouble with the error reporting so I wanted to contribute to improve it. In some of the cases the error reports came up were so unrelated it took me some time to eventually figure it out.

I would like to list a few of them here:

1) One of the very basic one is that in some cases where we may have an indentation error, it is not reported which file has that error. It just throws 

indentation error in views.py 

 For a new developer it may appear that the error is in the views.py file in the root directory(if one such exists) but the error may actually be in any of the views.py file of the apps.

2) Another error that bugged me for a long time was related with comment_was_posted signal. I made a mistake in the listener function for the comment_was_posted signal So whenever I posted a comment, I got the error

IntegrityError at /comments/post/

The integrity error was at the listener of the signal, but the url does not depict that.

3) Another point (it may be intentional) is that if some attribute is missing in the Queryset or the attribute name is wrongly written (in the then  template) a TemplateError is not raised. It just fails silently. Personally, I feel that it should throw some error, otherwise it can lead to some bugs that might be difficult to discover.

These are some of the errors that, if reported would have made things easier for me. Although I have used django extensively, I am not quite familiar with the error reporting facility. I have forked the git repository on github and will go through it in the next few days.

Since this is also listed as a topic for GSoC 2012, I am interested in applying for that. Meanwhile it would be great if I can be suggested some pointers.

Cheers

Sachin Gupta

[Andrew Godwin]

On 19/03/12 18:12, Sachin Gupta wrote:
> Hi,
>
> My name is Sachin Gupta and I am student of Indian Institute of
> Technology Roorkee, in my final year of undergraduate course in Computer
> Science. I have been developing a project entirely based on Django for

> the last 4 months. Here is the link <http://www.mycareerstack.com/> and

Hi Sachin,

A few comments from myself:

- The indentation error issue is relatively minor, I'd say - that's a
core Python error, and relatively uncommon (especially if you use a
linter, which I always recommend to people)

- Signals generally can be confusing as they make the control flow
jump around - however, if you're planning to make it more obvious what's
happened, we'd like to see a clear description of what you're going to
improve. The current error page will show you the signal handler towards
the bottom of the traceback, after all.

- Silent template failure is a deliberate design decision in Django,
though it was made many years ago - the idea was that a template editor
couldn't write a template that crashed the site. If you're planning to
change that, you'll need to have good reasoning why and backwards
compatability worked out for all the applications that rely on this
behaviour (some people rely on it and don't realise it - you'll break a
lot of sites if you just change the errors in there to be page-breaking).

I'd recommend you have a look through the
https://code.djangoproject.com/wiki/BetterErrorMessages page in
particular and look at some of the ideas in there - as each particular
area is quite small in scope, we'd be looking for a decent number of
error fixes to form a GSOC proposal that would be considered enough
work. There's some more meaty errors to fix in django.db, for a start.

Andrew

[Sachin Gupta]

Hi Andrew

As about the silent template failure I was not very sure if it was a deliberate design decision, but since it a deliberate design decision I would not like to change it. Since I did both the backend and template editing, it appeared to me that some error should have come.

But I would like to make the error reporting from signals a little better. What I would like to do is to trace the control flow and throw the error according to the context of the flow. About how I plan to do that, I need to go through the code base thoroughly and will try to come up with a method.

I went through the https://code.djangoproject.com/wiki/BetterErrorMessages page. 

Today I will go into the following errors 

Some of the django.db errors and also at Ticket:#15126, when a user forgets a trailing comma in a single-item tuple then the error message is quite misleading.

Could you guide me what number of error fixes would be good work for GSOC proposal. Also if there are any class of Django errors that are of greater concern (like django.db)

Regards

Sachin

[Sachin Gupta]

Hi Andrew

I am going through the errors on this page https://code.djangoproject.com/wiki/BetterErrorMessages particularly the django.db errors. The error which is listed on the page might not be updated

For the error message

OperationalError: Unable to close due to unfinalised statements

The context is not correct. I tried using a file that does not have write permission for sqlite3, but the error that came up is not what is listed above. The error message was quite appropriate in this case

django.db.utils.DatabaseError: attempt to write a readonly database

So is there something which I am not getting correctly?

Regards

Sachin

[Andrew Godwin]

On 20/03/12 07:18, Sachin Gupta wrote:

> Could you guide me what number of error fixes would be good work for
> GSOC proposal. Also if there are any class of Django errors that are of
> greater concern (like django.db)

There's no clearly defined "number" that would be good - we'll be
looking at your schedule that's on the proposal, instead, to make sure
that you've scheduled the fixes with the right amount of time and that
you've got enough work.

As for which ones are of greater concern, that's a difficult question to
answer - everyone has their own "favourite" (my particular nemesis is
the Postgres transaction-is-aborted one). I'd suggest looking through
django-users, StackOverflow, etc., to get an idea of what's tripping
people up the most.

> For the error message
>
> OperationalError: Unable to close due to unfinalised statements
>
> The context is not correct. I tried using a file that does not have write permission for sqlite3, but the error that came up is not what is listed above. The error message was quite appropriate in this case
>
> django.db.utils.DatabaseError: attempt to write a readonly database
>
> So is there something which I am not getting correctly?

I'm not sure - I've never had that one myself. It might have only been
with a previous version of the sqlite library or Python binding - have a
look through the history on the wiki page to see when it was put in
there, and by whom.

Andrew

[Sachin Gupta]

It seems most of the errors on this page https://code.djangoproject.com/wiki/BetterErrorMessages are very old. It states that if the attribute enctype="multitype/form-data" is not sent then the following error comes up

TypeError at ...
string indices must be integers

However if this is the case then I am getting a form error, saying that the file field is required. If the field attribute null is set True then no error comes up at all.

Would it be a good idea to change this from a 'form' error to a different kind of error that would state that the enctype attribute is not set for the given form?

[Daniel Sokolowski]

FYI: for my development settings I set: TEMPLATE_STRING_IF_INVALID = 'UNDEFINED_VAR: %s'  which tells me which variables are undefined.

 

It has some quirks (password reset form in admin link fails or something) but it’s easy to live with during development.

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/cuYearvU_OoJ.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Andrew Godwin]

Well, is that error possible to detect sensibly? These tiny questions
aren't what you should be asking now - we really want to see a
well-rounded application with a list of what you plan to tackle (it
doesn't have to be precise, just state the main problem areas), and a
demonstration of some possible ways you might solve it.

Attempting to pick the errors and the correct solutions now is too
fragile - if it turns out those errors are hard to fix, or the potential
error you want to raise isn't working for whatever reason (perhaps it
interrupts the call stack of something else), you'll need to work around it.

We want to see the ability to think independently in an application -
your mentor isn't there to continually answer questions for you, they're
there to check up on your progress now and again and answer the
occasional design decision/gnarly core Django question. The ability to
work independently, make good decisions and research/justify them well
is a big part of GSOC, and something we're looking for.

Andrew