Catching error messages to show meaningful explanation of failures

[kryaksy]

Support Question

I've encountered an issue where various CSV conversion errors are being logged to the console, which makes it challenging to capture and display meaningful messages to the user. These errors seem to abort the update process unexpectedly.

Attached is a screenshot illustrating the errors:

I am looking for a way to properly capture these errors so that I can provide a meaningful and user-friendly response instead of these raw messages. The current behavior is not conducive to a good user experience, as the console logs are not visible to the end-users.

Could you advise on best practices for capturing these errors within the code?

Ideally, I would like to intercept these errors before they hit the console, and then log them or display a custom error message to the user. Any pointers or examples would be greatly appreciated.

[texodus]

I don't understand - these aren't user errors, they are errors in your usage of the API (sending invalid data to update()). What is the use case for reporting these?

(edit - I've moved this to a discussion below (rather than Issue), GitHub's UI does not make this clear IMO since it uses the same color for "closed" vs "moved")

[kryaksy]

It seems I made a mistake in my previous explanation – apologies for the confusion. As you pointed out, the initial construction does indeed throw errors. However, it's clear now that conversion errors are not a concern when creating a table.

The actual scenario involves updating an existing table with a poorly formatted CSV file, rather than creating a new one. Therefore, my focus returns to handling errors that may arise during the table.update process. If you need, I can prepare a repro for this case.

[texodus]

The actual scenario involves updating an existing table with a poorly formatted CSV file, rather than creating a new one.

Please explain the actual scenario, then.

[kryaksy]

We're having trouble importing data into our predefined database tables with CSV files. The data types in the CSV don't match what our tables are set up for. Does this cover the actual scenario you were asking about? If not, please guide me on how to explain it better.

[texodus]

No, that's about as clear as mud. The table() constructor does exactly what you are asking for - it will throw validation errors, and you can use table.schema() to check what column types Perspective inferred if you want to pass this validated data along to another predefined database. Trying to do this by creating an empty Perspective table and updating it is not the intended use case for update(), as I've said several times now this is the wrong method to use for user input validation - this method is for updating a Perspective Table with more data from a server that has already performed validation, not from a user.

[kryaksy]

you can use table.schema() to check what column types Perspective inferred if you want to pass this validated data along to another predefined database

Thanks for the suggestion. It's definitely a more suitable and acceptable method compared to our current approach. Ideally, though, we would prefer to intercept the messages that Perspective is already managing. While it might seem like I'm insisting on something trivial, it's really about gaining access to a feature you already have.

[texodus]

While it might seem like I'm insisting on something trivial, it's really about gaining access to a feature you already have.

Adding error handling to update() is the farthest thing from trivial.