I’m using exec to execute Python code the user typed in. As part of this, I’d like to display meaningful error messages when they have syntax errors in their code.
On a normal Python installation on my desktop, printing out the args attribute of the SyntaxError gives me something like:
('invalid syntax', ('<string>', 1, 4, 'x 10\n'))
It’s a tuple that includes information like the line number and the character offset of the error.
On the client side in Anvil, the args attribute of the SyntaxError gives me:
('bad input',)
That seems to be the generic syntax error message and there’s no indication of line number or offset.
Is this a limitation in Skulpt? Is there some way to invoke exec that will provide the missing line and offset information?
Both of those SyntaxErrors were generated from the same code run in the different environments:
It’s on my back burner list of features to add to skulpt.
Internally this is implemented - else you’d never see tracebacks in anvil - but it’s not exposed in the same way that python exposes its traceback .
Edit: as a hugely inconvenient workaround you could re exec the code on the server to get the correct traceback details. You get the benefit of client side execution when it works and only do the slow thing for SyntaxErrors.
The workaround works, thanks, and the amount of code I’ll be dealing with will be small, so it doesn’t introduce that much of a delay. It’ll definitely work until Skulpt returns the same information.
Edit: Any chance of getting traceback support in general in Skulpt? It’d be great if, in a function, I could know the line number of the code currently being executed.
That’s bizarre! str(e) does not return the same thing that e does when it’s assigned to the label text. Skulpt must be doing something different with the two cases.
Thanks, I’ll try that and see if I can avoid the server call for syntax errors.
The hack tickles the underlying Skulpt architecture in just the right way.
(Its string representation in Javascript happens to be different to the string representation in Python).
Worth noting that it’s somewhat fragile and is likely to stop working at some point in the future.
Though that would likely coincide with supporting a python way to access the formatted traceback.