# Error Handling

The SDK provides a way to handle errors in a centralized way. You can provide your own error handling logic, or use the default one.

## Error Propagation

In case something is wrong with the application settings or the credentials are invalid, you can throw an explanatory message that will then be visible on the UI side.

For example, check if entered credentials are valid:

```js title="index.js"
configuration.projectIntegration.checkConnection = (credentials) => {
  if (!credentials.password  || credentials.password.length < 6) {
    throw 'Password is too weak';
  }
  // or call a service API with those credentials and check if request will be successful
};
```

If you need to manually control the user's session, you can throw an error with a `401` code, then your application will automatically perform a logout action.

For example, if your service has some special session duration, timeout, or additional conditions not covered by this framework:

```js title="index.js"
configuration.projectIntegration.getIntegrationFiles = async ({
  credentials,
  settings
}) => {
  // do a request/custom logic here
  const sessionStillValid = false;

  if (!sessionStillValid) {
    throw {
       message: 'session expired',
       code: 401
    }
  }

  // business logic
}
```

**Note:** The options above available only for the [Project Integration](/app-project-module/project-integration/) app type.

## Error Interceptor

You can also provide interceptor to catch errors and process them (e.g. to log them in the centralized place):

```js
import * as Sentry from '@sentry/node';

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  tracesSampleRate: 1.0,
});

configuration.onError = ({ error, context }) => {
  if (context) {
    console.log(context.jwtPayload);
    console.log(context.clientId);
    console.log(context.crowdinId);
  }
  Sentry.captureException(error);
};
```

You can also enable the Sentry browser interceptor with Replays by adding `SENTRY_DSN` to the `.env` file.

## Debug Mode

Turn on the debug mode and the application will log everything (useful for debugging):

```js
configuration.logger = {
  enabled: true
};
```

Or you can even pass your own function to log messages (e.g. send them to an external monitoring system):

```js
configuration.logger = {
  enabled: true,
  log: ({ message, context }) => {
    if (context) {
      console.log(context.clientId);
      console.log(context.crowdinId);
      console.log(context.jwtPayload.context.project_id);
    }
    console.log(message);
  }
};
```

## Disable Global Error Handling

All the `unhandledRejection` and `uncaughtException` errors will be handled by default and logged, and the Node process will not be killed.

Usually this means that the code was not properly designed and contains unsafe places. And this built-in behavior is not always suitable.

Therefore, you can disable it:

```js
configuration.disableGlobalErrorHandling = true;
```

## Disable Logs Formatter

By default, the framework comes with a built-in log formatter. This module is designed to modify the standard console methods, ensure that the messages are properly formatted for integration with the ELK, and provide middleware for Express to work seamlessly with these methods on the frontend.

It is possible to opt out:

```js
configuration.disableLogsFormatter = true;
```