Prisma Integration (in progress)
ds-express-errors can automatically identify and map Prisma errors into appropriate HTTP errors and responses.
Prisma integration works automatically and does not require Prisma to be added as a dependency of ds-express-errors.
- Basic integration
- Supported errors
- Configuration
- Strict error detection
- Example
- Resulting responses
1. Basic Integration
No additional configuration is required to use the Prisma mapper.
Add errorHandler after your application routes:
import express from 'express'
import { errorHandler } from 'ds-express-errors'
const app = express();
// Your routes
// Add Error Handler at the very end
app.use(errorHandler);When a supported Prisma error reaches errorHandler, ds-express-errors identifies it and maps it to the appropriate HTTP error.
2. Supported Errors
The Prisma mapper recognizes the following Prisma error types:
PrismaClientKnownRequestErrorPrismaClientUnknownRequestErrorPrismaClientRustPanicErrorPrismaClientInitializationErrorPrismaClientValidationError
Info
For PrismaClientKnownRequestError, the library also maps supported Prisma error codes to appropriate HTTP statuses.
| Prisma Code | Production Message | HTTP Status |
|---|---|---|
P2000 | Invalid input value | 400 |
P2001 | Resource not found | 404 |
P2002 | Resource already exists | 409 |
P2003 | Invalid reference | 400 |
P2005 | Invalid data | 400 |
P2006 | Invalid input value | 400 |
P2007 | Invalid reference | 400 |
P2011 | Required value is missing | 400 |
P2014 | Invalid relation | 400 |
P2015 | Requested resource not found | 404 |
P2021 | Internal server error | 500 |
P2022 | Internal server error | 500 |
P2025 | Resource not found | 404 |
P2027 | Internal server error | 500 |
P1001 | Service unavailable | 503 |
P1002 | Service unavailable | 503 |
P1003 | Internal server error | 500 |
3. Configuration
By default, all available mappers are enabled.
If you want ds-express-errors to use only selected mappers, configure them with needMappers:
import { setConfig } from 'ds-express-errors'
setConfig({ needMappers: ['prisma'] })Note
With this configuration, the built-in Prisma mapper is enabled while other built-in third-party mappers are not used.
4. Strict Error Detection
By default, ds-express-errors follows its zero dependency policy and identifies supported third-party errors without requiring Prisma as its own dependency.
If stricter error detection is required, Prisma error classes can be provided through errorClasses.
This allows the library to use the supplied Prisma classes for error identification instead of relying on the default detection mechanism.
Info
Strict detection is optional. The Prisma mapper works without it.
import { setConfig } from 'ds-express-errors'
import { Prisma } from '@prisma/client'
setConfig({
errorClasses: { Prisma }
})5. Example
A Prisma operation can be used normally inside your route or controller:
const user = await prisma.user.create({
data: {
email: req.body.email
}
})For example, if the email violates a unique constraint, Prisma can throw a PrismaClientKnownRequestError with code P2002.
The error can then reach the ds-express-errors error handler through your normal Express error flow.
app.use(errorHandler)ds-express-errors recognizes P2002 and maps it to 409 Conflict.
You do not need to manually check the Prisma error code and create the corresponding HTTP error for every route.
6. Resulting Responses
For a supported Prisma error, the final response follows the standard ds-express-errors response format. (configured by setConfig())
For example, a P2002 error in production is mapped to:
{
"status": "fail",
"message": "Resource already exists"
}Warning
url, stack, method are available in development mode, if you want to change that setting, you can redefine them by setConfig
To see how Production and Development responses differ, visit the Configuration part
Look at formatError property
ds-express-errors