issue_comments

TIL about how the stack inspection works: https://til.simonwillison.net/python/find-local-variables-in-exception-traceback

Steps to reproduce:

echo '{"v": 34223049823094832094802398430298048240}' | sqlite-utils insert /tmp/blah.db row -

Demo: ``` $ echo '{"v": 34223049823094832094802398430298048240}' | sqlite-utils insert /tmp/blah.db row -
Error: Python int too large to convert to SQLite INTEGER

sql = INSERT INTO [row] ([v]) VALUES (?); parameters = [34223049823094832094802398430298048240] ```

``` OverflowError: Python int too large to convert to SQLite INTEGER

import sys def find_variables(tb, vars): to_find = list(vars) found = {} for var in to_find: if var in tb.tb_frame.f_locals: vars.remove(var) found[var] = tb.tb_frame.f_locals[var] if vars and tb.tb_next: found.update(find_variables(tb.tb_next, vars)) return found ... find_variables(sys.last_traceback, ["sql", "params"]) {'params': [34223049823094832094802398430298048240], 'sql': 'INSERT INTO [row] ([v]) VALUES (?);'} ```

I'm going to use a bit of a dirty trick for this one: I'm going to recursively inspect the stack on an error and try to find the sql and params variables.

That way I can handle this all at the CLI layer without changing the exceptions that are being raised by the Python library.

Yeah this error message could certainly be more helpful.

I thought OverflowError might be one of the SQLite exceptions: https://docs.python.org/3/library/sqlite3.html#exceptions - but it turns out it's actually reusing the Python built-in OverflowError class: python import sqlite3 db = sqlite3.connect(":memory:") caught = [] try: db.execute("create table foo (number integer)") db.execute("insert into foo (number) values (?)", [34223049823094832094802398430298048240]) except Exception as e: print(e) caught.append(e) isinstance(caught[0], OverflowError) Here's where that happens in the Python sqlite3 module code: https://github.com/python/cpython/blob/058fb35b57ca8c5063d16ec818e668b3babfea65/Modules/_sqlite/util.c#L123-L124