Closed matteo-cristino closed 6 days ago
No it's ok to me to propagate the error, since we can't know how the fetch
sentences will be implemented in plugins
We could do somithing like this in slangroom.ts
try {
// slangrom_execute_statement
} catch(e) {
if (e instanceof FetchError) {
// throw nice colored error
}
throw e; // left for wrong no catched error in the plugins (should not happen)
}
or is it not worth it in you opinion?
IMHO not needed
Since the improvements in error reporting done in slangroom one thing (along with zenroom error that are next to be done) has been left behind. The error returned by
fetch/fethOpne/fetchonnect
https://github.com/dyne/slangroom/blob/de0850af5fbd15b5996a55a72aab551ea4fecd33/pkg/core/src/plugin.ts#L535-L542In case a variable used by a statement, that uses
fetch
, is not found the error that the user would see is justIn order to have better error reporting (with lines, colour and so on) also in this case the only thing that I see is to modify all
ctx.fetch
withand modify where it is called with
In the same way it will be done for
fetchOpen
andfetchConnect
.Any better idea? 💡