where is the panic from?
If it occurs during executing the go function called from java, it's an option to make your go function recover, convert it to an error, and return an error which will be translated into a java exception.

The scenario I was testing was a Go function called from Java. Would be nice not to have to wrap all my external functions with panic/recover and have the runtime just support this, but maybe I'm asking too much.

To be a bit clearer, I'm not expecting any of my Go code to panic. But if I'm accessing an array out of bounds and the app is crashing for half my users, I want to have reporting that tells me that.

one option David Crawshaw suggested is to make gobind generate a code that recover and translate the panic to java exception.
cc @crawshaw

A Go panic has a lot of technical similarities to Java exceptions, but several conventional differences. Java exceptions are part of normal programming, Go panics are not.

We may be able to match the conventions by throwing a java.lang.Error. While throwable, it's not a subclass of java.lang.Exception, so the usual try { } catch (Exception e) {} boilerplate won't get catch it.

(It is more than a little confusing that Java Errors are like Go panics, and Java Exceptions are like Go errors.)

The only concern left is any potential performance impact from the defer/recover block, but I believe the language barrier will always incur a more significant overhead.

I took a stab at implementing this: https://go-review.googlesource.com/#/c/11920/

Feedback welcome. Haven't written C in years, and JNI code in... ever. :)

CL https://golang.org/cl/11920 mentions this issue.

What was wrong with the suggestion of replacing exit(2) with abort(3)? Not every Go call originates from java, and it seems more appropriate for a library (libgojni.so) to abort rather than exit the foreign main program.

after chatting with @alandonovan the other day, I also realized that turning the panic into a java error addresses only part of the problem. There could be background goroutine causing crash, some library underneath deciding to crash, gc panics, or deadlock(not sure if it applies to library). In order to capture these cases, I also wish we could use abort instead of exit. @crawshaw @ianlancetaylor

That makes sense to me. Any benefit in translating to Error where we can (i.e. in Go code directly invoked from Java) and aborting when we can't? Maybe cleaner stack traces on the Errors?

@rsc pointed out runtime has already a way to change the program crash behavior by setting GOTRACEBACK env var and we may be able to utilize the similar hook.

http://golang.org/pkg/runtime/

"If GOTRACEBACK=crash, the per-goroutine stack traces include run-time functions, and if possible the program crashes in an operating-specific manner instead of exiting. For example, on Unix systems, the program raises SIGABRT to trigger a core dump."

On linux, the SIGABRT is handled and creates a core dump. On mobile, change the full stack trace to the Errors?

CL 12032 is my proposal for fixing this issue. GOTRACEBACK is read too early in the runtime initialization to allow for gomobile to fiddle with GOTRACEBACK and in any case I believe the aborting behaviour should cover all cases where C owns the process. In any case, GOTRACEBACK=crash behaviour includes GOTRACEBACK=2 behaviour (print runtime functions in tracebacks) which is not what we want here.