You could extend

YourSentryService

from the sentryService in the sentry module and override the captureException method. Create a default Exception type, check the exception.type against your own ignore list (ValidationException, maybe more…) and return null, or call super.captureException(…) if you don’t want to filter. Next thing to do is override the wirebox mapping for sentryService@sentry and map it to your own version. You can do that in an

afterAspectsLoad

interceptor, which fires when all modules have loaded.

The way it's set up now, every single CF exception is level

ERROR

since the module already supports min & max levels for reporting exceptions, seems like the path of least resistance to just let us catch and modify those levels on a per-exception basis

maybe an optional property on the exception object

because it's not just 'all exceptions of (type)', it's something I want to be able to toggle in particular catch blocks

You can send a different level to captureException, but it it sends all levels it receives to sentry. So your options are: modifying the onException in the moduleconfig which needs a module update. Or my suggestion which creates more or less your own filter on the captureException method by extending it, which doesn’t need a module update. I did a similar trick before on the cbswagger module where I wanted to change behaviour of the routesParser. I didn’t create a pull here because I needed flexibility and I was the only one using a modified version. But to be honest, I think this module could use a PR for an IgnoreExceptionTypes setting, so we could specify which Error types to ignore. Not so hard to create. Reading the setting in the captureException method and ignore where appropriate.

If you have code like this

try {
  model.validate();
} catch( validationException e ) {
  // Deal with vaildation error
}

then the framework will never "see" that exception and neither will Sentry

I don't know exactly where you're throwing the validation exceptions and where you're catching them, but somewhere in there the framework (or a base handler, perhaps) is announcing the

onException

interception point.

I'm just trying to tack the code path first

The stack trace Sentry grabs is interesting in that it's reporting the validationManager itself as the source

we are two minor versions behind in cbvalidation but I don't see anything relevant to this there

It doesn't exist in the repo in the location that it shows in the stack trace above

how long ago did you use the rest hmvc app template?

Looks like it was quite a while ago. That file hasn't existed since the Coldbox 5 versions of the template I think https://github.com/coldbox-templates/rest-hmvc/blob/v1.29.0/modules_app/api/handlers/BaseHandler.cfc

function aroundHandler( event, rc, prc, targetAction, eventArguments ) {
	try {
		(basehandler prep plumbing)

			// Execute action
			if ( !prc.response.getError() ) {
				var actionResults = arguments.targetAction( argumentCollection = args );
			}	
		}
catch ( ValidationException e ) {
	(massage response object)
}

If aroundHandler weren't executing, prc.response wouldn't even be getting created, nor would the response object have all the things it's returning to us

Without being able to trace it

I'd put a check in the actual sentry service for one of the validation messages them dump the call stack and abort

That will at least show you if it's coming through an onException announcement or a logbox error message.

I'm asking what code path is calling Sentry to log it

Like how is this error being caught and wrapped up nicely in a bow for our API response object, and yet it's also triggering onException

the stack trace would tell me what else is running instead of it. 🙂