Martin.Maly at microsoft.com
Sun Dec 4 03:25:31 CET 2005
I am sorry you find the IronPython errors insufficient. We did make some changes in the error handling code, but didn't observe that the messages would get less clear. My quick test with the IronPython console revealed following issue. Please let me know if that is also what you are experiencing or if there are problems beyond that. Currently when we throw exception, the stack trace doesn't give enough information about the stack frames and functions on the stack:
>>> def f(a,b):
... return a/b
>>> def g(a,b):
... return f(a,b)
>>> def h(a,b):
... return g(a,b)
Traceback (most recent call last):
ZeroDivisionError: Attempted to divide by zero.
This is an unfortunate bug and we'll fix it. If there are scenarios beyond this one (I tried runnig/importing modules with parse errors, importing modules that generate exception, running modules that throw from the command line) and so far I feel the one problem I see is the one described above.
We'll fix this one, thanks for reporting the problem we overlooked!
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. de Hooge
Sent: Friday, December 02, 2005 12:15 PM
To: users at lists.ironpython.com
Subject: [IronPython] Debugging
I have a question about debugging IP code.
One of the nice and handy things about Python in general is that I can use a very simple and straigth way of debugging in many cases.
When I run a script that is not bugfree, Cpython often tells me quite effectively what is wrong and where.
Some well placed print statements will often do to find the cause of problems.
What really helps here is the fact that there's no compilation and linking delay.
IP's error reports were somewhat less clear and complete upto version 0.93, but I could live with them.
But ever since I've been using version 0.95, I often find myself completely in the dark when an error occurs.
Often the interpreter tells me vaguely what's wrong, but doesn't even bother to add a hint as to where in the code the problem arises.
Why this change? Probably I've missed something, maybe an option to IPConsole or something like that. Currently I find it quite timeconsuming to debug code this way.
Of course I can use a debugger (which will often take me right into the C# implementation code of IP, but I understand from other postings that I can avoid that by compiling IPConsole etc. without debugging info.) But as said: the very simple and straigth way of debugging using the interpreters exception messages, with just an indication of the problematic line of code, a stack trace and some well placed print statements has been very productive for me. Just starting up the debugger often takes much more time that find an error by means of exception messages used to.
Are there any plans to enhance interpreter error reports? Why have they become less complete than in previous versions, e.g. often lacking even line numbers. Or have I indeed missed some configuration possibilities? If so, what are they?
Jacques de Hooge
info at geatec.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironpython-users