Opened 6 years ago

Closed 2 years ago

Last modified 5 months ago

#9104 closed Cleanup/optimization (needsinfo)

FieldDoesNotExist is defined in "confusing" place.

Reported by: telenieko Owned by: nobody
Component: Core (Other) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Django has "django.core.exceptions" package/module where most exceptions are defined, including DB related ones (i.e: ObjectDoesNotExist). Lame users like me would expect FieldDoesNotExist to be defined on the same module but it's in django.db.fields

Maybe we could move the exception?

Attachments (0)

Change History (6)

comment:1 Changed 6 years ago by telenieko

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 6 years ago by mtredinnick

We can't move it (backwards compatibility is important), but we could add an alias in the other place, maybe.

However, the reason for its current location is that this is not an exception that correct user code will ever see. You will see something like ObjectDoesExist because that can happen naturally. But your code should never be catching FieldDoesNotExist, since that would just mean you had made an error in your code 99% of the time (there are some introspection cases where it might not. I guess that is why the admin interface is using it). So declaring the exception where it is actually used and then only using it internally isn't a bad thing.

What's the use-case where you actually need to ever import this exception?

comment:3 Changed 5 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:4 Changed 3 years ago by lukeplant

  • Severity set to Normal
  • Type set to Cleanup/optimization

comment:5 Changed 2 years ago by aaugustin

  • Easy pickings unset
  • Resolution set to needsinfo
  • Status changed from new to closed
  • UI/UX unset

Malcolm explained why the code is written in this way, and his question stays unanswered after years.

comment:6 Changed 5 months ago by nickname123

Just came across this looking for the exception with Google search.

My use case is that I have a model form with extra fields on the form than what the model defines. I use these extra fields to auto populate some of the model fields.

I am iterating through the form fields to add HTML5 attrs during init. I need to catch FieldDoesNotExist when I try to check if the model field has blank=True to determine if the formfield is required or not.

from django.db.models.fields import FieldDoesNotExist

def __init__(self, *args, **kwargs):
        super(FooModel, self).__init__(*args, **kwargs)
        for key in self.fields:
                mfield = self.instance._meta.get_field_by_name(key)[0]
            except FieldDoesNotExist:
                if not mfield.blank:
                    self.fields[key].widget.attrs["required"] = "required"

This isn't too important, so I am just leaving the comment in case Google brings me back here again before I grep.

Last edited 5 months ago by nickname123 (previous) (diff)

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.