Skip to content

Simplified the creation of Subclasses of GraphBasedCallGraph#1071

Merged
JonasKlauke merged 10 commits intodevelopfrom
feature/openCallGraphData
Sep 16, 2024
Merged

Simplified the creation of Subclasses of GraphBasedCallGraph#1071
JonasKlauke merged 10 commits intodevelopfrom
feature/openCallGraphData

Conversation

@JonasKlauke
Copy link
Copy Markdown
Collaborator

Potential Subclasses gained access to edges in the call graph.
Added printCaller and printCallee to simplify the adpation of the toString method
Added toDotEdge to simplify the export of a call in the dot file generation
Introduced optionals in the graph data handling.

Copy link
Copy Markdown
Collaborator

@swissiety swissiety left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems convenient - but does this possibly enable a developer to feel confident in a way that the analysis will not fail in cases it should? e.g. thinking that it worked because there is no error and just an empty collection is returned therefore no fact exists.

@JonasKlauke
Copy link
Copy Markdown
Collaborator Author

Are you saying i should print a warning?
I wasnt sure about it, it could happen often

@swissiety
Copy link
Copy Markdown
Collaborator

I'm not happy about the warnings either :D Because their are a hint but are often times ignored anyway if its not clear why they are shown or as long as there is no supervisor who complains about them.

We have a similar situation in the ViewTypeHierarchy - there we have to check if the TH contains the vertex/ClassType - and sometimes we already know they do exist because we got the vertex from the TypeHierarchy and in those cases we don't need the additional check. And if its not there we throw an exception so the caller can differentiate between: vertex is unknown and vertex has none of the desired properties the method should calculate (i.e. Collections.empty() would be returned in both cases otherwise). Please check if the analogy is applicable/reasonable in this use case.

@swissiety
Copy link
Copy Markdown
Collaborator

TLDR: is it avoidable to run into theses situations (where a log would (then) be printed)?

@github-actions
Copy link
Copy Markdown
Contributor

Documentation Preview.

Copy link
Copy Markdown
Collaborator

@swissiety swissiety left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice that this convenient and problem avoiding way was possible!
please justreintroduce the doc+update ;)

Copy link
Copy Markdown
Collaborator

@swissiety swissiety left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice that this convenient and problem avoiding way was possible!
please justreintroduce the doc+update ;)

@JonasKlauke JonasKlauke merged commit d6d411f into develop Sep 16, 2024
@JonasKlauke JonasKlauke deleted the feature/openCallGraphData branch September 16, 2024 11:36
@JonasKlauke JonasKlauke mentioned this pull request Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants