-1

I wish to harvest the exception stack to open debugger on new Thread while unblocking the thread which threw the original exception. Is it possible in Java?

In Squeak, this method does the work:

StandardToolSet>>#debugException: anException "For convenience. Construct a helper process to debug an exception that occurred in the active process later on so that the active process can (try to) resume. Uses a temporary variable to access and copy the signaler context now before it gets GC'ed." | helperProcess | helperProcess := (Process forContext: anException signalerContext copyStack priority: Processor activeProcess priority) shouldResumeFromDebugger: false; yourself. Project current addDeferredUIMessage: [ helperProcess debugWithTitle: anException description full: false]. ```
Improve this question
15
  • Unclear what you're asking. You can print or get the stack trace from any exception on any thread, and there is nothing about that process or the catching process that blocks the catching thread. Commented Jul 20, 2020 at 3:14
  • Well, not so unclear if you read the Squeak method I posted. That explains clearly what I am after. In particular: anException signalerContext copyStack. I am uninterested in printing the stack trace, I wish to open a resumable debugger on the thrown exception, after having copied the stack out of the current Process to allow that current Process (my event loop) to proceed handling new message sends through its queue of pending sends. Without this the opening of a debugger blocks the event loop. It seems Java is incapable of providing this capability. Woe! So sad. Commented Jul 20, 2020 at 13:25
  • For starters, I cannot get an active stack from an Exception. So mark 1 for Squeak. Then, I suppose as a result of not being able to get a stack, one cannot create a new Thread on that stack. Continuations seem to require starting with a runnable, then yields throughout to stop processing and then resume the continuation where is was yielded. That will not work for PromisesLocal. The Java stack unwinds as handler contexts are sought. Just dumping good info over the gunwhale, into the sea, lost forever. So lame is Java. Get her some crutches and a wheelchair! Commented Jul 20, 2020 at 13:45
  • The Squeak method above StandardToolSet>>#debugException: cannot be implemented in Java. So LAME! Commented Jul 20, 2020 at 13:47
  • 1
    @RobertWithers No need to rant about Java, we all know that it is different from Smalltalk and that Smalltalkers love their Smalltalk... Commented Jul 20, 2020 at 14:11

2 Answers 2

Reset to default
1

Since you are asking with a reference to Squeak/Smalltalk, I am not sure how mighty you want your tool to be. Especially concerning the stack copying in anException signalerContext copyStack and possibly continuing the copied ongoing computation, the effort in Java might be significantly higher.

To simply view the stack frames, you can use Throwable.getStackTrace. You can get hold of an exception (which is a Throwable) by catching it somewhere with try { ... } catch (...) { ... }. You can also get the trace from the currently running Thread anywhere.

After extracting the stack trace, the thread will continue normally on the next line. So it is "unblocked", but not duplicated. Note that if the exception was thrown and you were in a catch block, the stack is already unwound to that point, unlike in Squeak/Smalltalk, which puts the exception handling frames on top of the signaling context. The Java program will continue after the catch block (unless you throw another or the same exception again).

The stack trace you thus obtain is not as powerful as dealing with Squeak/Smalltalk contexts. The StackTraceElements allow you to view some aspects of the trace, but not control them.

For anything debugger-like such as stepping and inspecting local variables, you could study the Java Debug Interface of the Java Platform Debugger Architecture (JPDA). Another way is to study how the Eclipse debugger works. I cannot tell you whether any of this allows you to debug a copy of a Thread though.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Oh! This is most unfortunate! What a limitation of the Java ecosystem! Note that if the exception was thrown and you were in a catch block, the **stack is already unwound to that point**, unlike in Squeak/Smalltalk, which puts the exception handling frames on top of the signaling context. It completely escaped me that this is the case. I have programmed a lot in Java and you get the debugger open on the catch block rewind and replay to the site the exception gets thrown. This is the dev workflow dealing with exceptions. In Squeak, the stack includes the signaler context.
This is for the Java version of Squeak's PromisesLocal, such that the exception is captured and displayed, while the event loop proceeds. In Squeak doIt to: Installer ss project: 'Cryptography'; install: 'PromisesLocal'. See my altered method: StandardToolSet>>#debugEventualException: anException
I have looked at: Continuations in Java Class Continuation Apache Commons Javaflow Why Continuations are coming to Java Project Loom On page 9 the slides shows the Continuation being created with SCOPE. What is SCOPE? Is that the stack?
1

I would change the title to In Java, how to handle exceptions without blocking?, if I could. The answer seems to be one cannot do so. Not possible..

So, this question is answered in the negative. Not possible.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.