if the VM was already open, provide a stacktrace where it was started

[cmacdonald]

No description provided.

[tshirtman]

hm, interesting, but it does feel a bit hacky, especially doing it for any run, maybe it should be behind a debug option/flag? maybe controlled by the debug log level? (though that doesn't seem great either). Maybe a more generic way to do it would be to allow a hook to be ran when the jvm starts, so the user would be able to get a pdb there and explore the frames that got them there themselves?

edit: also, i see you have the commit for autocloseable, and then a revert for it in there, if we are to merge that, i'd rather see these two removed through rebasing, or the whole thing squashed on merge, to avoid this making the history more confusing.

[cmacdonald]

I failed to rebase earlier. Could we resort to a new PR?

[tshirtman]

sure.

[tshirtman]

arf, i just tried my idea of a startup hook system, but it doesn't work because importing reflect is triggering the creation of the jvm, and reflect is imported in the __init__.py (to allow importing stuff from it instead of nested modules). For this reason, it's not possible to expose a register_startup_hook function anywhere in the package, as importing it does trigger the starting of the jvm, defeating the purpose of a startup hook.

I guess that's not a very pressing feature, so no need to break things left and right to make it work, i'll wait for better ideas :).

[cmacdonald]

and I bet you wanted to know where the JVM had started...

[tshirtman]

haha indeed, but i cheated and added a default hook in my list and put pdb inside it, and indeed that avoided me a lot of research.

[tshirtman]

my current "best idea" is to use env varibles, something like

in say module.py

def hook():
     # this function will be called

in shell

export JNIUS_VM_STARTUP_HOOK="module.hook"

And when in jnius, if that env var is detected, use importlib to load that symbol and call it.

[cmacdonald]

hi, I think this is overcomplicating things. If a dev is developing code, they get the exception, and they want to know where that happened. The formatting of a traceback in the exception isnt great, but it does the trick cheaply.

Your solution would involve restarting an additional time to add the debugger, when the dev could have already fixed the error by inspecting the stacktrace the first time?

[tshirtman]

true, i agree it's more practical, but it does feel dirty. and it's a bit confusing that the traceback displayed on the second start is the one from the first run, I'll think some more about it.

[cmacdonald]

I think both are shown; could the previous traceback be appended to the first? (I found it difficult to change this in Python, as the stacktraces arent attached to the Exception.)

The error is a coding error in one of the two places, so both stacktraces are valid/useful information.

Or is there the idea of exceptions with nested causes (each with a stacktrace)?

[tshirtman]

ok, this is certainly a useful feature, and i don't think anymore the way it's implemented is so bad it should prevent the feature to be merged, i wish there was a more generic way to do this, but it's not horrible.

[tshirtman]

rebase/merged localy in 384ae08

[cmacdonald]

Thanks @tshirtman