Skip to content

Audit our uses of INT_FATAL/INT_ASSERT/etc. to look for cases lacking ASTs? #21447

Open
@bradcray

Description

@bradcray

A piece of feedback we're getting from Arkouda developers is that our internal errors can be useful when they contain line number/filename information, and are far less so when they don't, since it effectively requires bringing us into the loop. In my own experience, I've found assertions or INT_FATALs that could easily mention the AST that they're referring to, yet don't (presumably due to developer laziness or confidence that we'd never hit that error).

This issue proposes that it could be a good investment of time for us to screen for such cases and look for ASTs to attach to them. For example, we could change the interfaces to require an AST pointer (as a means of finding such cases), look for ASTs to feed into them, and fall back to NULL in cases where there truly isn't one (though such cases seem like they would be few and far between?)

While this is not a glamorous task, it seems to me it also might not be that hard. One challenge is that we can't really test against internal errors very well (unless we already have a future tripping over it).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions