Django. Several DoesNotExist exceptions not reached

[FMZPNP]

When we try to catch mutiple DoesNotExist exceptions in different code blocks pylance says that those which are not the first will not be reached. But in fact, they will be reached and raise the corresponding exception.

Environment data

• Language Server version: v2023.2.10
• OS and version: macOS Monterrey v12.5.1
• Python version (& distribution if applicable, e.g. Anaconda): 3.10.9

Code Snippet

from django.db import models

class User(models.Model):
    email = models.EmailField(max_length=250)

class Notification(models.Model):
    message = models.CharField(max_length=250)

class Media(models.Model):
    file = models.FileField()

def do_things(user_id: int, notification_id: int, media_id: Media) -> None:
    try:
        user = User.objects.get(id=user_id)
        note = Notification.objects.get(id=notification_id)
        media = Media.objects.get(id=media_id)
    except User.DoesNotExist:
        raise Exception(f"User with id {user_id} does not exist.")
    except Notification.DoesNotExist:
        raise Exception(f"Notification with id {notification_id} does not exist.") # <- pylance marks this as not reached
    except Media.DoesNotExist:
        raise Exception("Example exception") # <- also marked as unreachable

Expected behavior

Do not mark the following exceptions as unreachable code

Actual behavior

From the second DoesNotExist exception the code is marked as unreachable.

[erictraut]

Please provide a self-contained, minimal code sample that demonstrates your issue. The code sample above references many symbols that are not stdlib symbols. You are presumably importing them from another file or defining them outside of the code snippet. Without the additional context, it's difficult to diagnose your problem.

[FMZPNP]

Please provide a self-contained, minimal code sample that demonstrates your issue. The code sample above references many symbols that are not stdlib symbols. You are presumably importing them from another file or defining them outside of the code snippet. Without the additional context, it's difficult to diagnose your problem.

Sorry. I've just updated it with additional context and the version of the Django package that we are using. Anything you need, just let me know and I will get back to you as soon as possible. Thank you.

[erictraut]

Thanks for the additional information.

This looks like a bug in the django type stubs that are bundled with pylance. The django implementation dynamically registers a DoesNotExist exception class for each model class, but the stubs model all of these as the same class. Pyright (the static type analyzer that underlies pylance) therefore concludes that the three except clauses are targeting the same exception class.

We can fix this by updating the bundled type stubs. In particular, we should update the Model class and replace class DoesNotExist(ObjectDoesNotExist): ... with DoesNotExist: ClassVar[type[ObjectDoesNotExist]].

[brdacost]

Are there any updates on this matter? I'm also facing this issue, but It only showed up suddently on my VS Code, maybe it was something on Pylance's latest update? ( I'm on version 2023.3.10 (1 March 2023) )

[debonte]

I mistakenly fixed this in https://github.com/microsoft/python-type-stubs instead of https://github.com/sbdchd/django-types.

A new PR is pending.

[debonte]

This issue has been fixed in prerelease version 2023.3.23, which we've just released. You can find the changelog here: CHANGELOG.md

[mateenkasim]

I am obviously late to this, but could I ask why pylance uses a fork off of typeddjango/django-stubs that is so many commits behind the parent? This issue is an example of something that was already fixed in the parent, leading to duplicate work.

[debonte]

why pylance uses a fork off of typeddjango/django-stubs that is so many commits behind the parent?

@bschnurr would know better, but I believe this issue mentioned in the README is the main reason:

Note: this project was forked from https://github.com/typeddjango/django-stubs with the goal of removing the mypy plugin dependency so that mypy can't crash due to Django config, and that non-mypy type checkers like pyright will work better with Django.

Happy to discuss if this is no longer true.