[yyyk]

My point is that you know the real source of the error, so there's no point for these terse messages. The example in the article, you know at point of conversion that you get a float, but instead you need to do a dance to get the original. Here it's a divide by zero - you can tell me the name of the variable too.

There's no need to repeat the infamous MSSQL "String or binary data would be truncated" message saga here - there's no reason you can't give much more verbose errors by default.

[yyyk]

For example, the error could have been '1064 is not a string value' or at least 'float64 is not a string value' etc.

[philrz]

Your observations are definitely valid. Structured errors were introduced in Zed some time ago, but as you highlight, they're not yet being generated in all the places they could be and with appropriate detail. There were a couple existing to-do items in the Zed backlog to make these enhancements in packages where it would have a high impact, but we've now created an additional Epic https://github.com/brimdata/zed/issues/4608 to gather these up and remind ourselves to address this in a comprehensive way. Thanks for helping to shine a light on this!