Comments (10)
- Change error messages without a major bump. Going forward, the semver contract will be on
code
.
This 💯
- Does this remove the need for the current error types defined here?
Hard to tell. I think that checking string constants is the safest way, hence also what node does, since you don't get issues with multiple classes being in the dependency tree, breaking instanceof
checks. However from a DX perspective it's nicer to import and check for instances. If we can't decide I think I would just mirror node core, and that's using string constants.
3. Should we restrict the codes to a known set, or allow modules (like
leveldown
) to return arbitrary codes?
Do you have an example of a module needing to create a new error type, or an error type that we have here that is only necessary with certain modules?
4. Should the codes have a certain prefix, like
ERR_LEVEL_
?
ERR_LEVEL_
seems to match https://nodejs.org/api/errors.html
from errors.
ERR_LEVEL_CORRUPTION
could be one that's useful for more types of backend
True. So we can document known error codes here; anyone that implements a new error should first consult that list. Much like node core.
I think the simpler the better here, as long as errors have ideally a code, or a message, people can deal with them. And these can be easily thrown from c++ as well.
My main motivation for opening this issue is merging abstract-leveldown
and levelup
, starting with API parity and being able to run their test suites on each other. Introducing error codes offers a non-breaking migration path - just for us (userland consumption of errors is a secondary concern):
- Add default
code
properties tolevel-errors
, e.g. a genericERR_LEVEL_READ
forReadError
- Add
code
argument tolevel-errors
constructors, so that the default generic codes can be made more specific - Add
code
to non-wrapped errors in(abstract-)leveldown
, esp. those that the test suite(s) currently check by message - Add
code
to wrapped errors fromlevelup
, esp. those that that the test suite(s) currently check by message
At that point, errors from either have a common property, they're documented in a central place, and messages no longer matter. It may remove the need to add level-errors
to abstract-leveldown
(and the need for #37, though I'll move ahead on that just to give us a choice) except in rare cases like normalizing NotFoundErrors (TBD).
from errors.
We have developed https://github.com/fastify/fastify-error as part of Fastify. It's a re-implementation in userland of the same pattern we use in Node.js core.
from errors.
I'm happy with https://github.com/vweevers/module-error because it's not http-centric, aligns with ecmascript spec (first argument being a message, second argument an options object), simple, browser-compatible, supports cause
, and a few other patterns that I'm using in airtap and elsewhere.
from errors.
Do you have an example of a module needing to create a new error type, or an error type that we have here that is only necessary with certain modules?
leveldown
could return more specific error codes like ERR_LEVEL_CORRUPTION
, a leveldb error that we currently only expose by error message. I'd prefer that over a generic ReadError
or WriteError
that only indicate what type of operation caused the error.
from errors.
Another example: levelup
directly exposes abstract-leveldown
iterators via db.iterator()
. Which has created the need in leveldown
to add safety checks that levelup
normally does, and throw errors that (I now realize) aren't wrapped in a level-errors
error. For example napi_throw_error(env, NULL, "iterator has ended")
. Same goes for abstract-leveldown
errors that we've had for a longer time.
from errors.
ERR_LEVEL_CORRUPTION
could be one that's useful for more types of backend 🤔 To me either way could work, difficult to tell.
Errors from db.iterator()
should be consistent indeed, good catch!
I think the simpler the better here, as long as errors have ideally a code, or a message, people can deal with them. And these can be easily thrown from c++ as well.
from errors.
This sounds fantastic to me, @vweevers 👏
from errors.
May not need level-errors
at all. Here's an example without: https://github.com/Level/transcoder/blob/b725dff60a75e037d3e626fe6d31b316726ffacc/lib/encoding.js#L92-L95
from errors.
Done in abstract-level
(see errors). It's not using level-errors
, as the only error that needed special handling (for backwards compat) is the not found error on db.get()
.
from errors.
Related Issues (9)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from errors.