##// END OF EJS Templates
Fix showing SystemExit exception raise inside except handler (#14503)...
Fix showing SystemExit exception raise inside except handler (#14503) Doing something like this: ```python try: 5 / 0 except Exception as e: raise SystemExit ``` was hitting an error inside UltraTB, creating a long traceback of its internals (which, ironically, UltraTB itself then displays correctly :-). `ListTB.get_exception_only()` calls the `ListTB.structured_traceback()` method *specifically* - even if `self` is a subclass, it won't use the subclass's method. However, the exception chaining in that method uses recursion by calling `self.structured_traceback()`, which will use a subclass's method. Tuples were added as an option there to support exception chaining, but not all of the machinery in connected classes expects a tuple. This just skips the exception chaining logic for the `etb=None` case, when we're showing the exception only. I'm not sure this is necessarily the best fix, but I didn't want to spend too much time following code around a module that's old enough to vote. Closes #12104

File last commit:

r27764:aefe51c6
r28830:d5762c16 merge
Show More
test_compilerop.py
68 lines | 2.1 KiB | text/x-python | PythonLexer
# coding: utf-8
"""Tests for the compilerop module.
"""
#-----------------------------------------------------------------------------
# Copyright (C) 2010-2011 The IPython Development Team.
#
# Distributed under the terms of the BSD License.
#
# The full license is in the file COPYING.txt, distributed with this software.
#-----------------------------------------------------------------------------
#-----------------------------------------------------------------------------
# Imports
#-----------------------------------------------------------------------------
# Stdlib imports
import linecache
import sys
# Our own imports
from IPython.core import compilerop
#-----------------------------------------------------------------------------
# Test functions
#-----------------------------------------------------------------------------
def test_code_name():
code = 'x=1'
name = compilerop.code_name(code)
assert name.startswith("<ipython-input-0")
def test_code_name2():
code = 'x=1'
name = compilerop.code_name(code, 9)
assert name.startswith("<ipython-input-9")
def test_cache():
"""Test the compiler correctly compiles and caches inputs
"""
cp = compilerop.CachingCompiler()
ncache = len(linecache.cache)
cp.cache('x=1')
assert len(linecache.cache) > ncache
def test_proper_default_encoding():
# Check we're in a proper Python 2 environment (some imports, such
# as GTK, can change the default encoding, which can hide bugs.)
assert sys.getdefaultencoding() == "utf-8"
def test_cache_unicode():
cp = compilerop.CachingCompiler()
ncache = len(linecache.cache)
cp.cache(u"t = 'žćčšđ'")
assert len(linecache.cache) > ncache
def test_compiler_check_cache():
"""Test the compiler properly manages the cache.
"""
# Rather simple-minded tests that just exercise the API
cp = compilerop.CachingCompiler()
cp.cache('x=1', 99)
# Ensure now that after clearing the cache, our entries survive
linecache.checkcache()
assert any(
k.startswith("<ipython-input-99") for k in linecache.cache
), "Entry for input-99 missing from linecache"