Python: Modernize the Unreachable Except Block query

[joefarebrother]

Replaces use of pointsTo.
Implements modelling for subclass relations of builtin exception types.

[github-actions]

QHelp previews:

python/ql/src/Exceptions/IncorrectExceptOrder.qhelp

Unreachable except block

When handling an exception, Python searches the except blocks in source code order until it finds a matching except block for the exception. An except block, except E:, specifies a class E and will match any exception that is an instance of E.

If a more general except block precedes a more specific except block, then the more general block is always executed and the more specific block is never executed. An except block, except A:, is more general than another except block, except B:, if A is a super class of B.

For example: except Exception: is more general than except Error: as Exception is a super class of Error.

Recommendation

Reorganize the except blocks so that the more specific except is defined first. Alternatively, if the more specific except block is no longer required, then it should be deleted.

Example

In the following example, the except Exception: will handle AttributeError preventing the subsequent handler from ever executing.

def incorrect_except_order(val):
    try:
        val.attr
    except Exception:
        print ("Exception")
    except AttributeError:
        print ("AttributeError")
        

References

• Python Language Reference: The try statement, Exceptions.
• Common Weakness Enumeration: CWE-561.

[joefarebrother]

Due to a strange dataflow issue, non-builtin classes do not seem to be tracked to the type of an Except block.
This results in some FNs for this query; however they are tolerable, so this PR will be made ready for review.

[Copilot]

Pull Request Overview

This PR modernizes the "Unreachable Except Block" query by replacing the outdated pointsTo mechanism with newer dataflow tracking and implementing comprehensive modeling for builtin exception type subclass relations.

• Replaced pointsTo with modern dataflow tracking and API graphs
• Added comprehensive builtin exception hierarchy modeling through a generated YAML file
• Enhanced the query to handle both user-defined and builtin exception types with proper subclass tracking

Reviewed Changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
python/ql/src/Exceptions/IncorrectExceptOrder.ql	Main query rewrite using new dataflow approach and ExceptType abstraction
python/ql/src/Exceptions/IncorrectExceptOrder.qhelp	Minor documentation updates and Python 3 reference links
python/ql/src/meta/ClassHierarchy/process-builtin-exceptions.py	New script to generate builtin exception hierarchy data
python/ql/lib/semmle/python/frameworks/builtins.model.yml	Generated YAML file containing builtin exception subclass relationships
python/ql/test/query-tests/Exceptions/general/*.expected	Updated test expectations reflecting new query behavior
python/ql/test/query-tests/Exceptions/general/exceptions_test.py	Added test cases for custom exception hierarchies
python/ql/test/query-tests/Exceptions/general/IncorrectExceptOrder.qlref	Updated test configuration to use inline expectations

Comments suppressed due to low confidence (3)

python/ql/src/Exceptions/IncorrectExceptOrder.ql:1

• Inconsistent spacing: line 68 has no trailing space while line 69 has a trailing space after 'pass'.

/**

python/ql/src/Exceptions/IncorrectExceptOrder.ql:1

• Inconsistent spacing: both lines 78 and 82 have trailing spaces after 'pass' which should be removed for consistency.

/**

python/ql/src/Exceptions/IncorrectExceptOrder.ql:1

• Inconsistent spacing: both lines 78 and 82 have trailing spaces after 'pass' which should be removed for consistency.

/**

[tausbn]

One suggestion, otherwise this looks good to me. The missing flow is annoying, but I don't see a quick fix (other than digging into the data-flow library and adding this flow).

[tausbn]

The many uses of <class-stuff> or <builtin-stuff> in the various member predicates suggests that it might be better to create two separate subclasses of ExceptType that each override the (abstract) predicates on this type in a different way.

[joefarebrother]

Perhaps, though that approach may be a bit longer.