Filtres d’exception
La seule différence entre la couche de filtre d’exception HTTP et la couche websocket correspondante est que, au lieu de lancer HttpException
, vous devez utiliser WsException
.
throw new WsException('Invalid credentials.');
Avec l’exemple ci-dessus, Nest gérera l’exception lancée et émettra le message d’exception avec la structure suivante :
{ status: 'error', message: 'Invalid credentials.'}
Filtres
Les filtres d’exception websocket se comportent de manière équivalente aux filtres d’exception HTTP. L’exemple suivant utilise un filtre instancié manuellement. Tout comme avec les applications basées sur HTTP, vous pouvez également utiliser des filtres à portée de passerelle (c’est-à-dire, préfixer la classe de passerelle avec un décorateur @UseFilters()
).
@UseFilters(new WsExceptionFilter())@SubscribeMessage('events')onEvent(client, data: any): WsResponse<any> { const event = 'events'; return { event, data };}
Héritage
En général, vous créerez des filtres d’exception entièrement personnalisés conçus pour répondre à vos besoins d’application. Cependant, il peut y avoir des cas d’utilisation où vous souhaiterez simplement étendre le filtre d’exception de base et remplacer le comportement en fonction de certains facteurs.
Pour déléguer le traitement des exceptions au filtre de base, vous devez étendre BaseWsExceptionFilter
et appeler la méthode héritée catch()
.
import { Catch, ArgumentsHost } from '@nestjs/common';import { BaseWsExceptionFilter } from '@nestjs/websockets';
@Catch()export class AllExceptionsFilter extends BaseWsExceptionFilter { catch(exception: unknown, host: ArgumentsHost) { super.catch(exception, host); }}
L’implémentation ci-dessus est juste une structure illustrant l’approche. Votre implémentation du filtre d’exception étendu inclurait votre logique métier personnalisée (par exemple, le traitement de diverses conditions).