Thread error handler java

Thread error handler java

When a thread is about to terminate due to an uncaught exception the Java Virtual Machine will query the thread for its UncaughtExceptionHandler using Thread.getUncaughtExceptionHandler() and will invoke the handler’s uncaughtException method, passing the thread and the exception as arguments. If a thread has not had its UncaughtExceptionHandler explicitly set, then its ThreadGroup object acts as its UncaughtExceptionHandler. If the ThreadGroup object has no special requirements for dealing with the exception, it can forward the invocation to the default uncaught exception handler.

Method Summary

All Methods Instance Methods Abstract Methods
Modifier and Type Method and Description
void uncaughtException (Thread t, Throwable e)

Method Detail

uncaughtException

Any exception thrown by this method will be ignored by the Java Virtual Machine.

  • Summary:
  • Nested |
  • Field |
  • Constr |
  • Method
  • Detail:
  • Field |
  • Constr |
  • Method

Submit a bug or feature
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
Copyright © 1993, 2023, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. Also see the documentation redistribution policy.

Источник

Advanced exception handling in Java -Thread.UncaughtExceptionHandler

Today I want to talk about Java’s Thread.UncaughtExceptionHandler and how it can help us catch those unexpected scenarios where our code would come to a halt.

All of us developers out there are dealing, daily, with code execution that went wrong. Be it exceptions, errors or anything that breaks our normal code flow, it happens. That is fine — all part of a day’s job! If you think your code is flawless, wake up! There is no such thing.

Lets start with a simple example. Here’s a naive method that takes user input, divide them, print and return the result to the caller:

Simple enough.
Now since we aren’t checking the input arguments for valid values, what will happen when the user enters zero as the value for argument argB? all hell break loose 🙂

Exception in thread “main” java.lang.ArithmeticException: / by zero

Now, we all know some of the “tools” we have to mitigate and defend our code like the infamous try-catch which will — should the code break, catch the exceptions for us and let us decide what to do with them:

But we can’t be wrapping every single line of code with a try-catch, that would be just plain awful in so many levels. So how do we handle those times where some part of our code threw an exception and we didn’t catch it?

Come to the rescue -Thread.UncaughtExceptionHandler

Lets consider this scenario — you lunched an app into production with a lot of active users which run your app daily and bugs are starting to show up.

Of course you have a nice, detailed log file about every important detail in the app which gets uploaded on a regular basis and you start to analyze the logs just to realize that in the scenario of a crash all code execution, including your log prints are stopped and the crash stack, which is what you need so bad in order to solve this issue is not in the logs.

Setting an UncaughtExceptionHandler on your threads is your app’s last stop before it crash, which lets you deal with exactly that — save that last pieces of information, close resources, shutdown gracefully which eventually will help you solve your bug.

The UncaughtExceptionHandler is an interface inside the Thread class (I’ll just call it handler for brevity). Lets read what the docs has to say about it:

So basically when a thread such as the main thread is about to terminate due to an uncaught exception the virtual machine will invoke the thread’s UncaughtExceptionHandler for a chance to perform some error handling like logging the exception to a file or uploading the log to the server before it gets killed.

It is important to understand how it works.

Every Thread is a member of a ThreadGroup and if the terminated thread doesn’t have an explicitly set handler than it will forward to the thread group handler. If the thread group doesn’t hold any special handler for such cases, it will eventually call it’s default uncaught exception handler.

Setting this handler is a per-thread base solution. Thread A will not use Thread’s B handler and vice versa. It is not a symmetric relation. Unless your threads are all a part of the same thread group and you have explicitly set an UncaughtExceptionHandler on the thread group, your threads can have different handlers performing different things in such scenarios where the thread terminates.

Setting up a handler is as simple as it gets — just create your own by implementing the interface:

and set your handler to the thread, usually the main thread on GUI applications since uncaught exceptions will make the entire app crash:

Last thing that I should add — George, one of the readers mentioned I should delegate the exception back to the original UncaughtExceptionHandler, this is to give back the control of exceptions to the systems. Otherwise we will “swallow” those exceptions and we might continue running in a some broken app state which is a bad thing. Crashing is probably a better choice than running in a wrong state. Thanks for pointing this out George!

And… thats it, were done!

So we’ve learned what is an UncaughtExceptionHandler and how it can serve us dealing with crashes and bugs in production when otherwise — the part that we really need in our log file wouldn’t appear- the crash stack trace. Yes there are different services out there like Crashlytics that will help on that area and are very powerful tools but hey, how do you think they work behind the scenes? hint — UncaughtExceptionHandler.

Hope it will help someone out there. This is my first blog post and I’d love to hear what you think.

Источник

Thread error handler java

Every thread has a priority. Threads with higher priority are executed in preference to threads with lower priority. Each thread may or may not also be marked as a daemon. When code running in some thread creates a new Thread object, the new thread has its priority initially set equal to the priority of the creating thread, and is a daemon thread if and only if the creating thread is a daemon.

When a Java Virtual Machine starts up, there is usually a single non-daemon thread (which typically calls the method named main of some designated class). The Java Virtual Machine continues to execute threads until either of the following occurs:

  • The exit method of class Runtime has been called and the security manager has permitted the exit operation to take place.
  • All threads that are not daemon threads have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.

There are two ways to create a new thread of execution. One is to declare a class to be a subclass of Thread . This subclass should override the run method of class Thread . An instance of the subclass can then be allocated and started. For example, a thread that computes primes larger than a stated value could be written as follows:

The following code would then create a thread and start it running:

The other way to create a thread is to declare a class that implements the Runnable interface. That class then implements the run method. An instance of the class can then be allocated, passed as an argument when creating Thread , and started. The same example in this other style looks like the following:

The following code would then create a thread and start it running:

Every thread has a name for identification purposes. More than one thread may have the same name. If a name is not specified when a thread is created, a new name is generated for it.

Unless otherwise noted, passing a null argument to a constructor or method in this class will cause a NullPointerException to be thrown.

Nested Class Summary

Nested Classes
Modifier and Type Class and Description
static class Thread.State

Field Summary

Fields
Modifier and Type Field and Description
static int MAX_PRIORITY

Constructor Summary

Constructors
Constructor and Description
Thread ()
Thread (ThreadGroup group, Runnable target, String name, long stackSize)

Method Summary

All Methods Static Methods Instance Methods Concrete Methods Deprecated Methods
Modifier and Type Method and Description
static int activeCount ()
static void sleep (long millis, int nanos)

Methods inherited from class java.lang.Object

Field Detail

MIN_PRIORITY

NORM_PRIORITY

MAX_PRIORITY

Constructor Detail

Thread

Thread

Thread

Thread

Thread

Thread

Thread

If there is a security manager, its checkAccess method is invoked with the ThreadGroup as its argument.

In addition, its checkPermission method is invoked with the RuntimePermission(«enableContextClassLoaderOverride») permission when invoked directly or indirectly by the constructor of a subclass which overrides the getContextClassLoader or setContextClassLoader methods.

The priority of the newly created thread is set equal to the priority of the thread creating it, that is, the currently running thread. The method setPriority may be used to change the priority to a new value.

The newly created thread is initially marked as being a daemon thread if and only if the thread creating it is currently marked as a daemon thread. The method setDaemon may be used to change whether or not a thread is a daemon.

Thread

This constructor is identical to Thread(ThreadGroup,Runnable,String) with the exception of the fact that it allows the thread stack size to be specified. The stack size is the approximate number of bytes of address space that the virtual machine is to allocate for this thread’s stack. The effect of the stackSize parameter, if any, is highly platform dependent.

On some platforms, specifying a higher value for the stackSize parameter may allow a thread to achieve greater recursion depth before throwing a StackOverflowError . Similarly, specifying a lower value may allow a greater number of threads to exist concurrently without throwing an OutOfMemoryError (or other internal error). The details of the relationship between the value of the stackSize parameter and the maximum recursion depth and concurrency level are platform-dependent. On some platforms, the value of the stackSize parameter may have no effect whatsoever.

The virtual machine is free to treat the stackSize parameter as a suggestion. If the specified value is unreasonably low for the platform, the virtual machine may instead use some platform-specific minimum value; if the specified value is unreasonably high, the virtual machine may instead use some platform-specific maximum. Likewise, the virtual machine is free to round the specified value up or down as it sees fit (or to ignore it completely).

Specifying a value of zero for the stackSize parameter will cause this constructor to behave exactly like the Thread(ThreadGroup, Runnable, String) constructor.

Due to the platform-dependent nature of the behavior of this constructor, extreme care should be exercised in its use. The thread stack size necessary to perform a given computation will likely vary from one JRE implementation to another. In light of this variation, careful tuning of the stack size parameter may be required, and the tuning may need to be repeated for each JRE implementation on which an application is to run.

Implementation note: Java platform implementers are encouraged to document their implementation’s behavior with respect to the stackSize parameter.

Method Detail

currentThread

yield

Yield is a heuristic attempt to improve relative progression between threads that would otherwise over-utilise a CPU. Its use should be combined with detailed profiling and benchmarking to ensure that it actually has the desired effect.

It is rarely appropriate to use this method. It may be useful for debugging or testing purposes, where it may help to reproduce bugs due to race conditions. It may also be useful when designing concurrency control constructs such as the ones in the java.util.concurrent.locks package.

sleep

sleep

clone

start

The result is that two threads are running concurrently: the current thread (which returns from the call to the start method) and the other thread (which executes its run method).

It is never legal to start a thread more than once. In particular, a thread may not be restarted once it has completed execution.

Subclasses of Thread should override this method.

If there is a security manager installed, its checkAccess method is called with this as its argument. This may result in a SecurityException being raised (in the current thread).

If this thread is different from the current thread (that is, the current thread is trying to stop a thread other than itself), the security manager’s checkPermission method (with a RuntimePermission(«stopThread») argument) is called in addition. Again, this may result in throwing a SecurityException (in the current thread).

The thread represented by this thread is forced to stop whatever it is doing abnormally and to throw a newly created ThreadDeath object as an exception.

It is permitted to stop a thread that has not yet been started. If the thread is eventually started, it immediately terminates.

An application should not normally try to catch ThreadDeath unless it must do some extraordinary cleanup operation (note that the throwing of ThreadDeath causes finally clauses of try statements to be executed before the thread officially dies). If a catch clause catches a ThreadDeath object, it is important to rethrow the object so that the thread actually dies.

The top-level error handler that reacts to otherwise uncaught exceptions does not print out a message or otherwise notify the application if the uncaught exception is an instance of ThreadDeath .

interrupt

Unless the current thread is interrupting itself, which is always permitted, the checkAccess method of this thread is invoked, which may cause a SecurityException to be thrown.

If this thread is blocked in an invocation of the wait() , wait(long) , or wait(long, int) methods of the Object class, or of the join() , join(long) , join(long, int) , sleep(long) , or sleep(long, int) , methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException .

If this thread is blocked in an I/O operation upon an InterruptibleChannel then the channel will be closed, the thread’s interrupt status will be set, and the thread will receive a ClosedByInterruptException .

If this thread is blocked in a Selector then the thread’s interrupt status will be set and it will return immediately from the selection operation, possibly with a non-zero value, just as if the selector’s wakeup method were invoked.

If none of the previous conditions hold then this thread’s interrupt status will be set.

Interrupting a thread that is not alive need not have any effect.

interrupted

A thread interruption ignored because a thread was not alive at the time of the interrupt will be reflected by this method returning false.

isInterrupted

A thread interruption ignored because a thread was not alive at the time of the interrupt will be reflected by this method returning false.

destroy

isAlive

suspend

First, the checkAccess method of this thread is called with no arguments. This may result in throwing a SecurityException (in the current thread).

If the thread is alive, it is suspended and makes no further progress unless and until it is resumed.

resume

First, the checkAccess method of this thread is called with no arguments. This may result in throwing a SecurityException (in the current thread).

If the thread is alive but suspended, it is resumed and is permitted to make progress in its execution.

setPriority

First the checkAccess method of this thread is called with no arguments. This may result in throwing a SecurityException .

Otherwise, the priority of this thread is set to the smaller of the specified newPriority and the maximum permitted priority of the thread’s thread group.

getPriority

setName

First the checkAccess method of this thread is called with no arguments. This may result in throwing a SecurityException .

getName

getThreadGroup

activeCount

The value returned is only an estimate because the number of threads may change dynamically while this method traverses internal data structures, and might be affected by the presence of certain system threads. This method is intended primarily for debugging and monitoring purposes.

enumerate

An application might use the activeCount method to get an estimate of how big the array should be, however if the array is too short to hold all the threads, the extra threads are silently ignored. If it is critical to obtain every active thread in the current thread’s thread group and its subgroups, the invoker should verify that the returned int value is strictly less than the length of tarray .

Due to the inherent race condition in this method, it is recommended that the method only be used for debugging and monitoring purposes.

countStackFrames

This implementation uses a loop of this.wait calls conditioned on this.isAlive . As a thread terminates the this.notifyAll method is invoked. It is recommended that applications not use wait , notify , or notifyAll on Thread instances.

This implementation uses a loop of this.wait calls conditioned on this.isAlive . As a thread terminates the this.notifyAll method is invoked. It is recommended that applications not use wait , notify , or notifyAll on Thread instances.

An invocation of this method behaves in exactly the same way as the invocation

dumpStack

setDaemon

This method must be invoked before the thread is started.

isDaemon

checkAccess

If there is a security manager, its checkAccess method is called with this thread as its argument. This may result in throwing a SecurityException .

toString

getContextClassLoader

If a security manager is present, and the invoker’s class loader is not null and is not the same as or an ancestor of the context class loader, then this method invokes the security manager’s checkPermission method with a RuntimePermission («getClassLoader») permission to verify that retrieval of the context class loader is permitted.

setContextClassLoader

If a security manager is present, its checkPermission method is invoked with a RuntimePermission («setContextClassLoader») permission to see if setting the context ClassLoader is permitted.

holdsLock

This method is designed to allow a program to assert that the current thread already holds a specified lock:

getStackTrace

If there is a security manager, and this thread is not the current thread, then the security manager’s checkPermission method is called with a RuntimePermission("getStackTrace") permission to see if it’s ok to get the stack trace.

Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this thread is permitted to return a zero-length array from this method.

getAllStackTraces

The threads may be executing while this method is called. The stack trace of each thread only represents a snapshot and each stack trace may be obtained at different time. A zero-length array will be returned in the map value if the virtual machine has no stack trace information about a thread.

If there is a security manager, then the security manager’s checkPermission method is called with a RuntimePermission("getStackTrace") permission as well as RuntimePermission("modifyThreadGroup") permission to see if it is ok to get the stack trace of all threads.

getId

getState

setDefaultUncaughtExceptionHandler

Uncaught exception handling is controlled first by the thread, then by the thread’s ThreadGroup object and finally by the default uncaught exception handler. If the thread does not have an explicit uncaught exception handler set, and the thread’s thread group (including parent thread groups) does not specialize its uncaughtException method, then the default handler’s uncaughtException method will be invoked.

By setting the default uncaught exception handler, an application can change the way in which uncaught exceptions are handled (such as logging to a specific device, or file) for those threads that would already accept whatever «default» behavior the system provided.

Note that the default uncaught exception handler should not usually defer to the thread’s ThreadGroup object, as that could cause infinite recursion.

getDefaultUncaughtExceptionHandler

getUncaughtExceptionHandler

setUncaughtExceptionHandler

A thread can take full control of how it responds to uncaught exceptions by having its uncaught exception handler explicitly set. If no such handler is set then the thread’s ThreadGroup object acts as its handler.

Submit a bug or feature
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
Copyright © 1993, 2023, Oracle and/or its affiliates. All rights reserved. Use is subject to license terms. Also see the documentation redistribution policy.

Источник

READ  Python create exception type
Smartadm.ru