Runtime errors should generate a useful user experience

[mtoy-googly-moogly]

Lot's of places when we hit some "impossible" state, we just throw. This happens a lot in the SQL compilation. This is OK when the event is a bug. or a very rare exception. If this is caused by user error, then the user experience of this is bad. You get an blob of text and not much help in figuring out what to do.

Query load or run errors should have locations (much of the time the IR which causes a runtime error has locations in it), should have useful text, and should result at least in some sort of "click to go the line of code causing this error".

It's a big piece of work.

• The APIS all need to be re-worked so there is a way for the callers to receive the errors
• Then all the clients needs to have some UI allowing users to respond to runtime errors.
• Each user-sensitive throw needs to be examined and worked on until it can generate a useful error

I would be OK with still throwing, but having a special ReportableError class which has location information in it. It should also have error codes, so we could add to our error page with instructions on how to fix that particular error.

If we did the first two, we could then do the third thing one error at a time as people encounter them

[mtoy-googly-moogly]

OK, actually if we just add a new throwable for ReportableErrors then we don't need to change the API. We still need to change the clients who want to give a better user experience to catch the reportable errors.