Impact of blacklisted libraries and classes
This document describes the Impact blacklisted libraries and classes have on how Overops captures events and how they are displayed within OverOps.
Scenario 1 (Blacklisted Entry-point)
The entry-point of the call stack is part of a blacklisted class/library.
a throws the exception b c is blacklisted d e is blacklisted entry point
In OverOps that blacklisted class is skipped and the next class in the call stack is shown as entry-point.
a throws the exception b d as the entry point
Scenario 2 (Blacklisted Exception)
The class which throws the exception is blacklisted or part of a blacklisted library.
a blacklisted throws exception b c blacklisted d catches it e f blacklist entry point
As in Scenario 1, the blacklisted class is skipped and the next class in the stack is shown as the class having thrown the exception.
b throws exception d catches it e entry point
Scenario 3 (Blacklisted exception and catch frame)
Here both the class which throws the exception and the class which catches the exception are blacklisted.
a blacklisted throws exception b c blacklisted d blacklisted catches it e f entry point
We do not capture these events.
Scenario 4 (blacklisted catch frame but no blacklisted exception)
Here the class which catches the exception is blacklisted.
a throws exception b c blacklisted d blacklisted catches it e f blacklist entry point
In OverOps the class which catches the exception is not shown!
b throws exception e Entry Point
A message is provided which will tell you the exception was caught in 3rd party class.
You will need to toggle the Show 3rd party/utility methods switch to see the capture icon and the actual 3rd party class in the stack trace view.
These rules also apply to log events.
For example, the actual logging utility class which creates the log event is blacklisted (Best practice) which will cause that Overops skips that class and the next "meaningful" class will be shown in Overops, not the logging utility class.
Updated almost 3 years ago