Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Maybe flatten out exception tree

Ouverte
  • Quelque chose ne va pas ?
#41 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Refactorisation
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
python
Domaine
backend

Piste de recherche

Commencez par examiner la hiérarchie actuelle des exceptions ainsi que les modules proposés exceptions.general, exceptions.http, exceptions.opening, exceptions.kv_store et exceptions.acl. Examinez ensuite le générateur et sa gestion des collisions. Le travail est considéré comme terminé lorsque la hiérarchie et les noms sont validés, que l’aplatissement est implémenté sans modification involontaire des relations de parenté et que des protections contre les collisions sont ajoutées.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

This is a ticket for discussion and design, responding to Paul's comment about nested exceptions being awkward to reach for.

--

I spread all the errors out on the table and had a look. We can get a pretty nice result by dividing exceptions across 5 modules, while still saving ourselves from utterly changing the shape of the world (fighting the WIT forevermore). No more subpackages under exceptions, just 5 files:

  • exceptions.general:

    • All from types.error. I don't see a point in having a common superclass for these at all; there's no semantic, and it doesn't really help catchers narrow down what threw it, as many things throw these.
    • Move HttpInvalid, HttpUser, and HttpIncomplete to exceptions.http, though.
    • It's unfortunate GenericError exists, as it sound a lot like UnexpectedFastlyError. UnexpectedFastlyError should become private, as it indicates a bug in our code if it's thrown. People definitely shouldn't be catching it. Catch Exception or FastlyException if you want a catch-all.
    • Rename GenericError to OtherError to get a little closer to its meaning. "Generic" suggests to me a superset of the other errors, while "Other" unambiguously indicates it's not one of those errors.

  • exceptions.http:

    • ErrorWithDetail with a better name, like HttpError.
    • All the send-error-detail exceptions error-with-detail carries (not currently generated). Map any ErrorWithDetail that has (optional) details directly onto these, subclassing HttpError.
    • All the trailer-errors. Rename Error to OtherError.

  • exceptions.opening:

    • All open-error errors. This is actually a pretty semantically cohesive category.

  • exceptions.kv_store:

    • All kv-error errors.
    • There's another GenericError there. Rename it to OtherError.

  • exceptions.acl:

    • All the acl-errors. Rename GenericError to OtherError.

Open questions

  • Are we going to cause trouble for ourselves by changing the parentage of some errors, like making error's HttpInvalid superclass exceptions.http.HttpError (or perhaps some other common ancestor)? I rather think so. The common-ancestor approach sounds good. The error superclass is worthless, but the error-with-detail one may have meaning.

Name collisions (if we were to flatten everything into 1 module):

  • Error (x2), but we can probably remove the types.error.Error common superclass to make that go away.
  • GenericError (x4)
  • LimitExceeded (x2)
  • TooManyRequests (x2)
  • Unsupported (x2)

Paths not taken

We could deduplicate and have, say, ACL stuff and non-ACL stuff throw the same TooManyRequests error, but we'd be losing potentially important info for the catcher. So that's a bad idea. (Also, it could get messy if the 2 TooManyRequests errors later diverge in shape, which might happen if WIT grows subtyping.)

Thus, we must rename exceptions or divide up into modules.

If we flatten and rename, we get into trouble in the future when somebody introduces another InternalError and we never prefixed the KV one into KvStoreInternalError. I'm against preemptively prefixing the heck out of everything, because it gets wordy and this isn't Java. And does one really need to say HttpTrailerError? There are unlikely to be other kinds of trailer errors. But if we don't prefix universally, it becomes awkward to program against because you constantly have to look aside to see what we named things. So let's keep the names short and just make a better __repr__ instead if needed to clarify tracebacks.

Prerequisites

We'd need to add alarm bells about collisions in the generator so we don't accidentally template duplicate names into one module.

Langage dominant
Python
Étoiles
5
Forks
1
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de fastly/compute-sdk-python

Toutes les issues de fastly/compute-sdk-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.