I think this question is related to AppMon.
One reason I believe this is done by default is that this can add a lot of extra nodes to your PurePaths since absolutely every java exception will be included in them. This includes any exceptions regardless of whether they are handled or not. I have turned them back on in cases and gotten very limited value from them and for the most part they clutter up PurePaths, and make it difficult to find the real custom application level exceptions that are more commonly causing issues and sometime get you pointed in the wrong direction during triage say if an execpion is normal and handled later in the execution.
I'm not sure if you're asking how or why this is the case but I can only offer my opinions and experience with it. As Benjamin noted there are definitely cases where it may make sense to enable a handful of exceptions but in the grand scheme of things I agree with the decision to exclude them by default. You get a bit more visibility but this also comes with a cost in terms of clutter, confusion if exceptions are handles or unimportant, and overhead due to handling so much extra data.
Yeah, I understand these side effects of having all java.* exceptions, but at same time I think a Null Pointer Exception it's quite important to have it included by default. Of course you could always add it manually.
Thank you all!
I agree with James, I have seen the same at customers.
Normally, there are just far too many java.* exceptions happening, which makes it hard to tell whether there is a real problem going on at the moment or just business as usual.
I normally keep them suppressed, but there have been cases where I have allowed specific subcategories, for example java.sql (for database problems) or java.io (for network timeouts).
it might be important to note that Dynatrace still captures a NullPointerExceptions if it were thrown over a service boundary or other purepath node. let's say you have a web request and it fails with a NullPointerException. Dynatrace would capture that and would show it as a root cause. the same is true for all other services, even custom services. But if the customers code throws a NullPointerException at some point and captures it again before it reaches any service boundary that is guarded by a Dynatrace sensor we do not capture it. It was handled gracefully as we would say.
other exceptions, like application exceptions are captured at the point of origin, when they are thrown. So they will always show up.
the reason we do this is not specifically the NullPointer but because legacy code has a lot of control flow by exception. These exceptions would add a lot of noise, most of them could not be fixed and also have no impact on the result of a request.
Long story short, exceptions with impact on a service will always be captured, NPE included.