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.

  1. Basic integration
  2. Supported errors
  3. Configuration
  4. Strict error detection
  5. Example
  6. Resulting responses

1. Basic Integration

No additional configuration is required to use the Prisma mapper.

Add errorHandler after your application routes:

javascript

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:

  • PrismaClientKnownRequestError
  • PrismaClientUnknownRequestError
  • PrismaClientRustPanicError
  • PrismaClientInitializationError
  • PrismaClientValidationError

Info

For PrismaClientKnownRequestError, the library also maps supported Prisma error codes to appropriate HTTP statuses.


Prisma CodeProduction MessageHTTP Status
P2000Invalid input value400
P2001Resource not found404
P2002Resource already exists409
P2003Invalid reference400
P2005Invalid data400
P2006Invalid input value400
P2007Invalid reference400
P2011Required value is missing400
P2014Invalid relation400
P2015Requested resource not found404
P2021Internal server error500
P2022Internal server error500
P2025Resource not found404
P2027Internal server error500
P1001Service unavailable503
P1002Service unavailable503
P1003Internal server error500


3. Configuration

By default, all available mappers are enabled.

If you want ds-express-errors to use only selected mappers, configure them with needMappers:

javascript

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.


javascript

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:

javascript
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.

javascript
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:

json
{ 
	"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