Git Product home page Git Product logo

Comments (3)

annevk avatar annevk commented on August 13, 2024

"AbortError" is very specific and mainly for abort signals only. cc @domenic

I'd also recommend considering that implementations might want some flexibility going forward so requiring rather unique exceptions might not be worthwhile if web developers aren't expected to branch on the exception names anyway.

from fs.

jesup avatar jesup commented on August 13, 2024

If there's specific action an application might want to take for a specific failure mode, then tightly specifying errors would be useful. Otherwise tightly specifying errors doesn't have much benefit I can see; though specifying them avoids unintentional lock-in by developers who look for a specific (non-specced) error, and then break if it changes -- or if they use a different browser. However, we should be in alignment with how other specs do (or should) specify errors. @annevk ? @domenic ?

We throw SecurityError for some cases that violate security rules.

Instead of AbortError for non-implemented features, maybe NotSupportedError?

from fs.

domenic avatar domenic commented on August 13, 2024

So you definitely need to specify the error type, and all browsers need to agree. There's no option of not specifying the error type at all.

But you don't need to make sure every error type is used perfectly and maps to distinct cases, if developers don't need to distinguish between such cases. For example, you could just always throw a TypeError (the web platform's generic error). Or, you could just lump a bunch of error conditions together under "OperationError" DOMException, or "InvalidStateError" DOMException. That's a reasonable option.

Specific error type guidance you should be consistent with, which is unfortunately not written down or consistently applied, is:

  • Use "NotAllowedError" DOMException for permissions
  • Use "SecurityError" DOMException for security checks
  • Use "NotSupportedError" DOMException for not-yet-launched features
  • Use "AbortError" DOMException for operations that were aborted, usually in the sense of the developer requesting or causing the abort, usually via an AbortSignal.
  • Use "UnknownError" DOMException for internal, implementation-specific issues.

Note that "TypeMismatchError" DOMException is deprecated.

So yeah, there are some improvements you could make here to align better with the rest of the platform.

from fs.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.