[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