Re: Improved Error Reporting in Django - GSoC

[Andrew Godwin]

On 20/03/12 20:33, Sachin Gupta wrote:

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?


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

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Improved Error Reporting in Django - GSoC

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

From: Sachin Gupta 
Sent: Tuesday, March 20, 2012 3:18 AM
To: django-developers@googlegroups.com 
Subject: Re: Improved Error Reporting in Django - GSoC

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

-- 
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-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Improved Error Reporting in Django - GSoC

[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

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Improved Error Reporting in Django - GSoC

[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



-- 
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/-/p66JQSKUDkMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Improved Error Reporting in Django - GSoC

[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

-- 
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-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Improved Error Reporting in Django - GSoC

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


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

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.