Why send Java NPE stacktraces to RB admins?

I'm curious as to what you would expect your average Rollbase administrator to do with an e-mail from the system that simply contains an undecorated Java null pointer exception stacktrace...

java.lang.NullPointerException Customer: Agent ERP
java.lang.NullPointerException
	at com.rb.util.db.a69.<init>(a69.java:45)
	at com.rb.util.db.a74.getNewConnection(a74.java:171)
	at com.rb.util.db.a74.getConnection(a74.java:111)
	at com.rb.util.db.a67.getConnection(a67.java:39)
	at com.rb.util.db.Transaction.<init>(Transaction.java:56)
	at p5.FieldDefController.create(FieldDefController.java:94)
	at p5.a205.dispatch(a205.java:147)
	at org.apache.jsp.setup.objectView_jsp._jspService(objectView_jsp.java:114)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:724)

Even if we administrators were Java developers and prepared to 'dig in' to the code as such, it's closed source anyway so we couldn't! So, as far as I can see, sending stacktraces to non-developers is pointless, not to mention annoying!

I suggest you review your exception handling mechanism so that, if you need to send an error report to an RB admin, they can make sense of it, and will know how/where to report it and perhaps even provide some kind of 'one-click' bug-reporting mechanism.

Another approach could be to have an admin setting that allows an RB admin to give the system permission for these e-mails to be sent directly to your own bug management system.

Bear in mind, the RB admin wasn't necessarily the user who triggered the exception, and they will probably have *no* idea who it was or what they were doing at the time, and so I doubt that such a bug report (whether manual or automated) would yield enough information to provide a report that your developers could reproduce and resolve!

I don't know what to suggest, but please could you let me know if and how I can stop RB generating these stacktrace e-mails in the meantime, that would be appreciated.

Thanks.