Tipi di errore personalizzati
Definisca e generi dal backend tipi di errore personalizzati che vengano propagati correttamente al frontend.
Tipi di errore personalizzati è una lezione tRPC End-to-End Type Safe APIs gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento tRPC End-to-End Type Safe APIs, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso tRPC End-to-End Type Safe APIs include 4 lezioni in totale.
Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.
Why Custom Error Types?
In tRPC, we often use TRPCError for handling issues. But sometimes, you need more specific error types.
- Clarity: Custom errors make your code clearer about what went wrong.
- Specific Handling: Allows the frontend to react differently to distinct error conditions.
- Better Debugging: Provides more context than a generic error.
Let's learn how to define and use them!
Basic Custom Error Class
At its simplest, a custom error is a class that extends JavaScript's built-in Error class. This ensures it behaves like a standard error.
It usually takes a message and sets its own name property.
class MyCustomError extends Error {
constructor(message: string) {
super(message);
this.name = 'MyCustomError';
}
}
function main() {
try {
throw new MyCustomError('Something specific went wrong!');
} catch (error) {
if (error instanceof MyCustomError) {
console.log(`Caught: ${error.name} - ${error.message}`);
} else {
console.log(`Caught generic error: ${error.message}`);
}
}
}
main();tRPC's TRPCError
For tRPC to correctly understand and propagate errors, your custom errors should extend TRPCError from @trpc/server.
TRPCError requires an object with a code (e.g., 'NOT_FOUND', 'BAD_REQUEST') and a message. This code helps the client understand the error type.
Defining a tRPC Custom Error
Here's how you define a custom error for tRPC, ensuring it extends TRPCError and sets a relevant status code.
This example creates a UserNotFoundError. Notice we pass the tRPC code to the super() constructor.
import { TRPCError } from '@trpc/server';
class UserNotFoundError extends TRPCError {
constructor(userId: string) {
super({
code: 'NOT_FOUND',
message: `User with ID '${userId}' not found.`
});
this.name = 'UserNotFoundError';
}
}
function main() {
try {
throw new UserNotFoundError('user-123');
} catch (error) {
if (error instanceof TRPCError) {
console.log(`Error Code: ${error.code}`);
console.log(`Error Message: ${error.message}`);
}
}
}
main();Throwing Custom Errors (Backend)
Once defined, you can throw your custom error directly within your tRPC procedures (queries or mutations). tRPC will automatically catch it and send it to the client.
This allows your backend logic to signal specific issues clearly.
import { publicProcedure, router } from './trpc'; // Assume trpc setup
import { TRPCError } from '@trpc/server';
class UserNotFoundError extends TRPCError {
constructor(userId: string) {
super({ code: 'NOT_FOUND', message: `User ${userId} not found.` });
this.name = 'UserNotFoundError';
}
}
const appRouter = router({
getUser: publicProcedure
.input(z.string())
.query(async ({ input: userId }) => {
// Simulate database lookup
if (userId === 'nonexistent') {
throw new UserNotFoundError(userId); // Throw our custom error!
}
return { id: userId, name: `User ${userId}` };
}),
});
// Note: `z` for Zod input validation is assumed here
// The router itself is not runnable without a full server context.Frontend: Receiving Errors
On the frontend, when a tRPC procedure fails, the client-side tRPC library will throw an instance of TRPCClientError.
This error object contains the code and message from your backend TRPCError, allowing you to identify the specific issue.
Frontend: Identifying Custom Errors
To handle specific custom errors on the client, you can use a try...catch block and inspect the error object.
- Check
error.data.code: This is the most reliable way as it's directly from theTRPCErrorcode. - Check
error.message: Less reliable, but can be used for specific messages. instanceof(with shared types): If you share the custom error class definition between client and server, you can useinstanceof. This is common in monorepos.
Frontend Example: Handling UserNotFoundError
Here's how a React component (or similar frontend logic) might handle our UserNotFoundError using the error.data.code property.
This allows you to display a user-friendly message specific to the error.
import { trpc } from './utils/trpc'; // Assume trpc client setup
function UserProfile({ userId }: { userId: string }) {
const { data, error, isLoading } = trpc.getUser.useQuery(userId);
if (isLoading) {
return '<p>Loading user data...</p>';
}
if (error) {
if (error.data?.code === 'NOT_FOUND') {
return `<p>User with ID <b>${userId}</b> does not exist.</p>`;
} else {
return `<p>An unexpected error occurred: ${error.message}</p>`;
}
}
return `<h1>Welcome, ${data?.name}!</h1>`;
}
function main() {
// This function simulates component usage.
// In a real app, trpc.getUser.useQuery would trigger an API call.
console.log('Simulating UserProfile for existing user...');
// Assume UserProfile('user-123') would render 'Welcome, User user-123!'
console.log('Simulating UserProfile for nonexistent user...');
// Assume UserProfile('nonexistent') would render 'User with ID nonexistent does not exist.'
}
main();Quick Check
Which of the following are good reasons to define and use custom error types in tRPC, especially when extending TRPCError?
Recap: Custom Error Types
Great job! You've learned how to leverage custom error types in tRPC:
- Extend
TRPCError: For tRPC to correctly propagate your errors. - Specify
code: Use tRPC's error codes (e.g.,'NOT_FOUND') for standardization. - Throw on Backend: Signal specific issues from your procedures.
- Catch on Frontend: Use
error.data.codefor precise error handling.
This approach leads to more robust and user-friendly applications by clearly communicating backend issues to the client.
Domande Frequenti
La lezione «Tipi di errore personalizzati» è gratuita?
Sì — il testo completo di «Tipi di errore personalizzati» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso tRPC End-to-End Type Safe APIs, passa a CoddyKit PRO. Il corso tRPC End-to-End Type Safe APIs include 4 lezioni in totale.
Cosa imparerò in «Tipi di errore personalizzati»?
Definisca e generi dal backend tipi di errore personalizzati che vengano propagati correttamente al frontend. Eserciti tRPC End-to-End Type Safe APIs con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare tRPC End-to-End Type Safe APIs?
Non è richiesta alcuna esperienza precedente. tRPC End-to-End Type Safe APIs su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.
Quanto tempo richiede la lezione «Tipi di errore personalizzati»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione tRPC End-to-End Type Safe APIs?
Sì. Ogni lezione tRPC End-to-End Type Safe APIs include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Gestire gli errori tRPC in modo efficace
- Tipi di errore personalizzati
- Trasformatori di dati per la serializzazione
- Formattazione degli errori e feedback di validazione a livello di campo