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

Vernon Cole vernondcole at gmail.com
Fri Sep 10 16:37:45 CEST 2010


IMHO, StopIteration should never trigger a debugger. It is an expected
operation which will happen in many (most?) loops.  As an Exception, it
should be an exception -- not handled by the same code in the debugger.
--
Vernon


On Fri, Sep 10, 2010 at 12:04 AM, Tony Meyer <tony.meyer at gmail.com> wrote:

> > If you hit F5 and continue execution it should keep on running.  You can
> > also disable breaking on exceptions via Debug->Exceptions and uncheck the
> > "thrown" column for CLR exceptions.  It should just be breaking so you
> can
> > look around and seeing what's going on.
>
> 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?
>
> Thanks,
> Tony
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20100910/dfa80336/attachment.html>


More information about the Ironpython-users mailing list