While reading jvm specification I came across exception (2.10 Exceptions)
Most exceptions occur synchronously as a result of an action by the
thread in which they occur. An asynchronous exception, by contrast,
can potentially occur at any point in the execution of a program ...
What are the differences between the two types ?
Keeping reading, the specification gives and example of an asynchronous exception
An asynchronous exception occurred because: – The stop method of class
Thread or ThreadGroup was invoked, or – An internal error occurred in
the Java Virtual Machine implementation.
But what makes stop method of a class thread special in this regard ?
Can you explain the differences between the two and give some examples of them, other than the given ones ?
The stop method can be called from another thread which could leave the data altered by the thread stopped in an inconsistent state.
For this reason Thread.stop() is being removed. I suggest you not use it.
Can you explain the differences between the two and give some examples of them, other than the given ones
The difference is that an asynchronous exception is triggered by another thread at any point in the code.
They should not happen under normal operation.
A specific implementation of the JVM could have other errors but there is not exhaustive list.
There isn't much you can do about except shutdown gracefully.
Here's an example showing the two types of exception. Consider the following code snippets, which show the two kinds of exception being raised, and handled:
public static void main(String[] args) throws Exception {
try {
syncException();
} catch (RuntimeException re) {
System.out.println("-1-");
re.printStackTrace();
}
CompletableFuture<Void> f = null;
try {
f = asyncException();
} catch (RuntimeException ex) {
System.out.println("-2-" + Thread.currentThread().getName());
ex.printStackTrace();
}
try {
f.get();
} catch (Exception ex) {
System.out.println("-3-");
ex.printStackTrace();
}
}
A synchronous exception
private static void syncException() {
throw new RuntimeException("Sync exception #" + Thread.currentThread().getName());
}
And an asynchronous exception - raised in a different thread from the calling code:
private static CompletableFuture<Void> asyncException() {
return CompletableFuture.runAsync(() -> {
throw new RuntimeException("Async exception #" + Thread.currentThread().getName());
}, Executors.newFixedThreadPool(1));
}
Now, when that code is executed, the following stack traces are produced:
The synchronous exception's stack trace:
-1-
java.lang.RuntimeException: Sync exception #main
at stackoverflow.Main.syncException(Main.java:34)
at stackoverflow.Main.main(Main.java:11)
Note that -2- was not printed, because the exception was asynchronous. See the third catch block's stack trace for how asynchronous exceptions are handled. Note that the thread in which the exception was raised is different from the one printing the stack trace:
-3-
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Async exception #pool-1-thread-1
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
at stackoverflow.Main.main(Main.java:26)
Caused by: java.lang.RuntimeException: Async exception #pool-1-thread-1
at stackoverflow.Main.lambda$0(Main.java:39)
at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1626)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
An asynchronous exception, by contrast, can potentially occur at any point in the execution of a program ...
Just a comment on this: you'll notice that the code in thread pool-1-thread-1 could raise the exception any time of the main thread's execution. This is probably relative among threads. But in this example, the main thread being the main programe execution, we can say that the "Async exception #pool-1-thread-1" exception occurred asynchronously.
Related
I'm learning Java threads tutorial and can't understand the explanation of last question 'Threads and exceptions':
Now suppose we run this test:
#Test public void testThreadOops() {
new Thread(() -> { throw new Error("thread oops"); }).start();
}
Is a stack trace for Error: thread oops printed? ( ) Yes ( ) No
The test: ( ) Passes ( ) Fails
The explanation for this question is:
The Error occurs on the newly-created thread, terminating that thread with a stack trace on the console. But the test method testThreadOops returns normally – there is no exception on the main thread – and the JUnit test passes. It does not detect the oops.
Why is there no exception in the main thread?
Is a stack trace for Error: thread oops printed?
It depends.
An uncaught exception on a child thread (i.e. not the "main" thread) will be passed to the thread's uncaught exception handler, the threadgroup uncaught exception handler, or the default uncaught exception handler. These would typically be responsible for printing a stacktrace.
If you (or your framework) don't set a handler, the default behavior is to do nothing, and there won't be a stacktace anywhere.
(The methods for setting handlers are described in the javadocs for Thread.)
Why is there no exception in the main thread?
Because the exception is not thrown on the main thread. It is thrown ... and must be caught / handled ... on the child thread's stack.
Think of it this way. If an exception on a child thread was somehow rethrown on the parent thread, where would you catch it? How would you deal with it? What if it was a checked exception, and the context didn't allow that particular exception to be thrown?
There is no exception thrown in the main thread simply because this code doesn't throw an exception in the main thread. It starts a new thread, and throws an exception in that new thread - not in the main thread.
When an exception is thrown (and not caught) in a thread, that thread terminates, but it doesn't "pass" the exception back to the "parent" thread that started it in the first place. If that happened, any thread which started other threads would continuously be at risk of stopping at any time because of an exception thrown in one of its "child" threads. If the "parent" thread were stopped half-way through some computation, it could leave some data in an invalid state.
In the method below you are throwing an exception in the new thread you create not the main thread of the application. So no exception is thrown in the main thread.
new Thread(() -> { throw new Error("thread oops"); }).start();
Normally when an exception occurs in a thread it terminates itself instead of passing the exception in the main thread. This is to protect the main(parent thread) from stopping incase of child thread cause an exception.
I have the following RxJava 2 code (in Kotlin), which have an Observable that
disposable = Observable.create<String>({
subscriber ->
try {
Thread.sleep(2000)
subscriber.onNext("Test")
subscriber.onComplete()
} catch (exception: Exception) {
subscriber.onError(exception)
}
}).subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe({ result -> Log.d("Test", "Completed $result") },
{ error -> Log.e("Test", "Completed ${error.message}") })
While it is still Thread.sleep(2000), I perform disposable?.dispose() call, it will error out
FATAL EXCEPTION: RxCachedThreadScheduler-1
Process: com.elyeproj.rxstate, PID: 10202
java.lang.InterruptedException
at java.lang.Thread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:371)
at java.lang.Thread.sleep(Thread.java:313)
at presenter.MainPresenter$loadData$1.subscribe(MainPresenter.kt:41)
at io.reactivex.internal.operators.observable.ObservableCreate.subscribeActual(ObservableCreate.java:40)
I expect the dispose would help to cancel the operation silently, or at most, have the error catch with with the Log.e on the subscribe. However, it just crash as per the error message above.
Why did the Exception escape? Isn't dispose suppose to cancel the entire operation silently without crashing?
There is a combination of factors here:
dispose of a stream that uses subscribeOn also disposes of the thread used. This also involves calling Thread.interrupt() when using Schedulers.io(). This causes the exception in your case.
InterruptedException is an Exception thrown by Thread.sleep, so it is caught by your code and passed to onError like any other exception.
Calling onError after dispose redirects the error to the global error handler due to RxJava2's policy of NEVER throwing away errors. To work around this check subscriber.isDisposed() before calling onError or use RxJava 2.1.1's new subscriber.tryOnError.
if (!subscriber.isDisposed()) {
subscriber.onError(exception)
}
If you are using rxjava2, please add this in your initialisation code
RxJavaPlugins.setErrorHandler(t -> {
logger.log(Level.SEVERE,null, t);
});
Hope it helps
I'm try to run LDA algorithm using mallet library. When I try to run LDA with a set of parameters it's OK but with another set I have this error:
09-Oct-2014 23:50:24.354 INFO [http-nio-8084-exec-127] cc.mallet.topics.ParallelTopicModel.estimate <50> LL/token: -8.73265
09-Oct-2014 23:50:24.657 INFO [http-nio-8084-exec-127] null.null [beta: 0.00795]
09-Oct-2014 23:50:24.657 INFO [http-nio-8084-exec-127] null.null <60> LL/token: -8.6299
09-Oct-2014 23:50:24.957 INFO [http-nio-8084-exec-127] cc.mallet.topics.ParallelTopicModel.estimate <70> LL/token: -8.61982
09-Oct-2014 23:50:25.019 INFO [http-nio-8084-exec-127] null.null [beta: 0.00583]
09-Oct-2014 23:50:25.263 INFO [http-nio-8084-exec-127] cc.mallet.topics.ParallelTopicModel.estimate <80> LL/token: -8.89656
09-Oct-2014 23:50:25.402 INFO [http-nio-8084-exec-127] null.null [beta: 0.00484]
java.lang.ArrayIndexOutOfBoundsException: -1 at
cc.mallet.topics.WorkerRunnable.sampleTopicsForOneDoc(WorkerRunnable.java:489) at
cc.mallet.topics.WorkerRunnable.run(WorkerRunnable.java:275) at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at
java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at
java.lang.Thread.run(Thread.java:745) java.lang.ArrayIndexOutOfBoundsException: -1 at
cc.mallet.topics.WorkerRunnable.sampleTopicsForOneDoc(WorkerRunnable.java:489) at
cc.mallet.topics.WorkerRunnable.run(WorkerRunnable.java:275) at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at
java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at
java.lang.Thread.run(Thread.java:745)
My code look like:
try{
//call some function from library
} catch(Exception e){
System.out.println("LDA Exception")
}
How can catch exception caused by external jars? I have reed this question but it doesn't work for me. Any Idea?
EDIT:
My project is an restful webservice which it run on apache tomcat Server. I try to call lda algorithm in dopost function.
EDIT 2
Mallet is an open source library. So I tried to read code and I found the below code.
public class ParallelTopicModel implements Serializable {
int numThreads = 2;
public void estimate() throws IOException {
WorkerRunnable[] runnables = new WorkerRunnable[numThreads];
for (int thread = 0; thread < numThreads; thread++) {
runnables[thread] = new WorkerRunnable(numTopics, alpha, alphaSum, beta,
random, data, runnableCounts,
runnableTotals, offset, docsPerThread);
//some code
}
}
}
public class WorkerRunnable implements Runnable {
public void run() {
try {
//some code
} catch (Exception e) {
e.printStackTrace();
}
}
}
My webservice:
#POST
#Produces("application/xml")
public String getXml(#FormParam("xmlinput") String xmlinput) throws Exception {
try {
//call estimate function in ParallelTopicModel class
//return an xml;
} catch (Exception e) {
return "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" + "<modelingOutput>null</modelingOutput>";
}
So how can handle exceptions whiche produce WorkRunnable class in my web service. I want to ruturn an xml look like
`null
I have read a lot of questions like this and this but I don't found solution
The problem here is not that the call is to an external jar. Exceptions thrown by any method in your chain of calls, no matter where the actual class's bytecode is stored, are caught at the first catch block up the chain.
The problem you have here is that the exception occurs in a different thread. If you start a separate thread from your code, the exceptions in that thread are not passed on to your thread. As far as your code is concerned, that call has completed. If the code in the other thread doesn't catch them, they'll be caught by that thread's exception handler, if there is such a handler.
Runtime errors are usually caused by bad input, so the usual strategy to avoid them would be to understand why your parameters cause the array index in that method to be negative, and then make sure you never pass such parameters to that method.
If that is impossible, you may create an exception handler for the thread. This would work only if you are the one in control of creating the thread and you can set the handler in it.
You may want to look at this question for more about handling exceptions in threads.
Edit:
Since their WorkerRunnable code seems to catch all exceptions (and print a stack trace), there is no way to catch them yourself. You can do one of two things:
As I said above, check what parameters you passed caused the array out of bounds error, and avoid those conditions. Use an if statement and if the parameters are bad, print your <modelingOutput>null</modelingOutput> output - without running the modeling in the first place.
Use their source, change their catch clause to something that sets a variable that tells you there was an exception, compile it and use that jar instead of theirs. That's what Open Source is for. You may want to communicate with the maintainers of that library and tell them that it would be nice if they added a way to detect if an exception was caused by one of the sub threads.
I have been trying to find out how JVM handles runtime exception in RMI remote methods. I have a remote method that contains the following two methods:
doSomething(
print "doSomething thread id " + Thread.currentThread.getId()
)
fail(){
print "fail thread id " + Thread.currentThread.getId()
throw new RunTimeException
}
The behavior I saw was that even if method fail() is invoked, the thread on which the runtime exception was thrown is still not terminated. A sample output is:
fail thread id 16
stacktrace
...
doSomething thread id 16
doSomething thread id 16
The exception is caught. The caller will get a ServerException with your RuntimeException nested in it as the cause. The executing thread doesn't die.
I have a task scheduler implemented in my application. Basically, what i do is schedule some task's to be executed 4 times in a day (like 6 in 6 hours), so the system schedules it to: 00:00, 06:00, 12:00, 18:00.
Ok, i have a class (FlowJobController) which extends the Thread class and in the run() implementation i keep sleeping the thread in 60 to 60 seconds, so it's executed again to check if there's any task to be executed. If true, i run my Job.
Basically the main part it:
rSet = pStmt.executeQuery();
while (rSet.next()) {
long jobId = rSet.getLong("trf_codigo");
String ruleName = rSet.getString("reg_nome");
String ruleParameters = rSet.getString("trf_regra_parametros");
Job job = new Job();
job.setId(jobId);
job.setRuleName(ruleName);
job.setParameters(Functions.stringToList(ruleParameters, "\n"));
FlowJob flowJob = new FlowJob(this, job);
flowJob.start();
}
} catch (Exception ex) {
logger.error(WFRSystem.DEFAULT_USER, system.getCode(), ex);
} finally {
try {
DBConnection.close(pStmt);
DBConnection.close(rSet);
// executede 60 in 60 sec
Thread.sleep(60 * 1000);
} catch (InterruptedException ex) {
logger.error(WFRSystem.DEFAULT_USER, system.getCode(), ex);
}
}
The thing is: When the pStmt.executeQUery() returns records to be executed, it goes into the while and the error appears into the line: Job job = new Job();
The error is:
Exception in thread "FlowJobController" java.lang.NoClassDefFoundError: wfr/com/Job
at wfr.com.FlowJobController.run(FlowJobController.java:112)
Before this error i got this error:
25/09/2012 12:00:09 org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load wfr.com.Job.
The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1566)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at wfr.com.FlowJobController.run(FlowJobController.java:112)
The FlowJobController.java:112 is the Job job = new Job();
What am i doing wrong?
The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
If you are saying that your code deliberately threw the IllegalStateException exception, then that is the likely cause of the subsequent problems. If you throw an uncheck exception in static initialization, and that exception propagates, then the class initialization fails, and the class (and all classes that depend on it) are unusable. In this case, it looks like it also caused the webapp to be stopped.
If this is the problem, the solution is "don't do that". Fix whatever is causing the exception to be thrown.
The other possibility is that this is simply a missing class problem:
Well, that sounds not possible (to not be in the war) since i'm running into the eclipse environment and it's in the class folder directory and no errors is shown about not finding those classes...
The class loader won't be looking in the Eclipse classes folder. It will be looking in the webapp directory on your web container (Tomcat, Jetty, whatever).