Hacker News Reader

Silent failure and continuing to run on errors are common in interpreted languages. SAS has similar issues, most RDBMSs will continue to process queries after failures. It’s something you need to explicitly guard against.

View on HN

Are you sure about "most RDBMSs"? With the exception of SQLite and older versions of MySQL, all the databases that I've used are strict and fail the query immediately on error, will generally prevent silently dropping or truncating data, etc.

I'm one of the original authors of Presto, a distributed SQL engine for analytics on big data. From the beginning, we've been careful to follow the SQL standard and do everything possible to either return the correct answer or fail the query. For example, an addition or sum aggregation on an integer will fail on overflow rather than silently wrapping.

Returning an incorrect answer or silently corrupting your data is the worst thing a database can do.

What I mean is that if you run in batch mode they’ll fail a query and happily run the next. Generally, depending on the client, you need to handle begin/commit/rollback blocks yourself. This is pretty common in scripting languages. Unlike, for example Java, where an unhandled error will terminate the process.

Reply on news.ycombinator.com