Replies: 3 comments · 4 replies
-
|
Hi @Ericlm, did you get more info on this topic? |
Beta Was this translation helpful? Give feedback.
-
|
Not for now 😕. It would be great if the errors could be type-safe, with an "unknown error" of type |
Beta Was this translation helpful? Give feedback.
-
|
+1 for this! I asked an LLM and it suggested to check for the status and then cast the error type that I know will be raised. Like import type { components } from '$lib/api/schema'; // Your OpenAPI types
type CSVParsingErrorSchema = components['schemas']['CSVParsingErrorSchema'];
type HTTPValidationError = components['schemas']['HTTPValidationError'];
const {
data,
error: apiError,
response
} = await backendClient.GET("/imports/headers/", {
headers,
params: {
query: {
file_name: fileName
}
}
});
if (apiError) {
const status = apiError.response.status;
if (status === 400) {
const errorData = apiError.response.data as CSVParsingErrorSchema;
console.error("CSV error", errorData.message);
// Optionally show in UI
throw error(400, `Ogiltig CSV: ${errorData.message}`);
}
if (status === 422) {
const errorData = apiError.response.data as HTTPValidationError;
console.error("Validation error", errorData.detail);
throw error(422, "Valideringsfel vid uppladdning");
}
// Fallback
console.error("Unexpected API error", apiError);
throw error(500, "Något gick fel");
}hope you get the feel of it without knowing the details (or Swedish) |
Beta Was this translation helpful? Give feedback.
-
|
Wait, but isn't For me Does this actually work for anyone or is this just an LLM dream? |
Beta Was this translation helpful? Give feedback.
-
Yes, it is if (status === 422) {
const errorData = apiError.response.data as HTTPValidationError;
console.error("Validation error", errorData.detail);
throw error(422, "Valideringsfel vid uppladdning");
}but this is quite tedious |
Beta Was this translation helpful? Give feedback.
-
|
Well, for me it is I.e., there is really no data at all in my case, and casting would be pointless. From reading the source code I also believe it has to be this way, because what is returned as Are you by any chance using some kind of middleware that actually changes the semantics of |
Beta Was this translation helpful? Give feedback.
-
|
I did some research and I found out the following when using fetch: There are two possible failure modes: Either the request completes successfully but returns an error status, in this case the promise resolves and the response will have For more specifity you could create handler that checks the thrown |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello! I juste wanted to ask if it's possible to get the error types to properly handle error cases when making a request. Basically, I'm making a PUT and the request and response body are perfectly typed, but this is not the case of the error(s). Basically, the error is a union type of all possible and declared "wrong cases" (4**).
I wanted something more like switching on error statuses, and get typed-error messages, narrowed by these statuses.
Would it be "dangerous" to assume those types are safe, or is it better to try each possibility of the error union type, then have a fallback where only raw statusCode and text can help ?
Beta Was this translation helpful? Give feedback.
All reactions