add support for ad-hoc error messages not from a Throwable

[twiggy]

Currently in Report.java there the errors main text is pulled from.

public String getExceptionName() {
return throwable.getClass().getName();
}

This makes it hard to throw an error that isn't actually from a java throwable like a handled database error especially if you don't want to go through the hassle ( or in my case can't ) create MyException extends Exception style custom exception.

Another option might be to include a custom Throwable in the bugsnag API itself that overrode getClass() so getName() could return whatever we needed it to.

Thanks!

[fractalwrench]

Thanks for the report @twiggy. I'm a bit unclear on why the exception name would need to change, without changing the Throwable class?

[twiggy]

TLDR; I don't want see every java error look like this in the interface.

"""
java.lang.RuntimeException SomeUnrelatedClass.java: -1
The actual error I want to see
"""

Right now I could use the REST API which is what I'm probably going to have to use to call the error "My super duper database error" if I wanted it to be that. A realistic example might be "Switched country from USA to United States" and continue processing. Do I really need com.mycompany.SwitchedCountryNameError. I'm not using the native java language, but just the bindings so I don't have to roll REST calls. The current class name I get is super confusing and doesn't define the error I want. I need more control over what shows in the GUI.

Even in my python bindings every single error I have starts with "Exception" ...just wastes space in the GUI. Not all of us want to create a named exception for everything, or the named exception is to generic to be useful in the interface. For various reasons I need to call notify() directly in my apps.

This might actually be a design issue with your GUI, but my current error looks like this in the GUI which just isn't useful.

java.lang.RuntimeException sun.reflect.GeneratedConstructorAccessor59.newInstance:-1

If Report.java just had setExceptionName(), etc. and then default to using the throwable stuff if not overridden that would allow the consumers of this API to format their errors however they saw fit and not be constrained by opinionated versions specific to that languages bindings.

[fractalwrench]

I'm a bit unclear on how the Java Notifier is being used from Python - are you using Jython or a similar framework?

I can investigate whether exposing setExceptionName() on a Report object would make sense, but we probably wouldn't want to override getClass().getName().

[twiggy]

I'm not using java bindings from python.

I have apps written in multiple languages that are consuming each other. So sometimes we consume errors from one language, but report from another language\app for various reasons. The point is even if we are using a language binding, being stuck to that languages typical exception paradigm is very limiting.

The REST API calls are quite verbose. I can understand why Report.java's constructor takes a Throwable being its java, but sometimes it would be nice if there was a constructor like new bugsnag.Report( 'We had a big error', 'It happend in MyCode.code', 'The full details of the error are this....' )