For applications that have a high volume of "path not found" cases, the internal exception handling uses a lot of time to basically throw and catch the internal PathNotFoundException. There is no reason to have this internal exception have a stack trace at all and can be many times faster by suppressing that when the exceptions themselves are suppressed. Or alternatively, don't use this as an internal exception to signal "not found" and only throw an exception when the user isn't suppressing them.
This is a big performance gain when 90% of your JsonPath calls are "not found"
For more information on using exceptions in the case of "not found" style signalling as the common rather than rare case:
https://stackoverflow.com/questions/299068/how-slow-are-java-exceptions
It is an easy gain and easy performance improvement.
For applications that have a high volume of "path not found" cases, the internal exception handling uses a lot of time to basically throw and catch the internal PathNotFoundException. There is no reason to have this internal exception have a stack trace at all and can be many times faster by suppressing that when the exceptions themselves are suppressed. Or alternatively, don't use this as an internal exception to signal "not found" and only throw an exception when the user isn't suppressing them.
This is a big performance gain when 90% of your JsonPath calls are "not found"
For more information on using exceptions in the case of "not found" style signalling as the common rather than rare case:
https://stackoverflow.com/questions/299068/how-slow-are-java-exceptions
It is an easy gain and easy performance improvement.