[IronPython] Iteration via __getitem__ doesn't work in the Visual Studio debugging environment

Dino Viehland dinov at microsoft.com
Fri Sep 10 19:00:57 CEST 2010

Tony wrote:
> From my naive point of view, I would expect that the process continues
> running until (a) I stop/pause it, (b) a breakpoint is hit, or (c) an
> exception occurs that would normally stop the program (i.e. propagate
> all the way to the top).  Not every exception causes execution to
> break, e.g. this doesn't:
> a = {}
> try:
>     print a[1]
> except KeyError:
>     print "missing"
> Although this does (no exceptions when run outside the debugger or
> with CPython, of course):
> def myiterator():
>     yield 1
>     yield 2
>     raise StopIteration()
> for item in myiterator():
>     print item
> What is the distinction here?  Is the first considered "user handled"
> and the second not, even though it is correctly handled?  Is it that
> the iteration exceptions always cause the debugger to kick in?

This depends upon your settings.  If I break on all thrown exceptions 
checked I do have it breaking in on both of these.  If I have Just My
Code enabled in Tools->Options->Debugging->General and have User-unhandled
checked then I see it breaking on the 2nd one.  I believe that's because
VS sees the exception leaking through non-user code (the IronPython runtime)
and therefore is letting you know about it.  

There may be a way for us to handle this specific case if there's some
attributes we could apply to our code to make the debugger ignore it as
far as user-code is concerned - I'm not sure if those exist but I can look
around.   If that does exist, and we add it to the all the right places,
then you'll get your desired experience by having Just My Code enabled,
unchecking Thrown, and leaving user-unhandled checked.  If there's no way
for us to control this then we'll need to wait until we get better
debugger integration.

More information about the Ironpython-users mailing list