As we know if any error or any unchecked exception occurs then our program will halt, then what are the differences between those?
In short:
You can, and probably should, recover from an exception.
You can, but should not, recover from an error.
From the Error Javadoc:
An Error is a subclass of Throwable
that indicates serious problems that a
reasonable application should not try
to catch. Most such errors are
abnormal conditions. The ThreadDeath
error, though a "normal" condition, is
also a subclass of Error because most
applications should not try to catch
it.
Versus the Exception Javadoc
The class Exception and its subclasses
are a form of Throwable that indicates
conditions that a reasonable
application might want to catch.
So, even though an unchecked exception is not required to be caught, you may want to. An error, you don't want to catch.
Unchecked Exception:
The classes that extend RuntimeException are known as unchecked exceptions
Unchecked exceptions are not checked at compile-time rather they are checked at runtime.And thats why they are also called "Runtime Exception"
They are also programmatically recoverable problems but unlike checked exception they are caused by faults in code flow or configuration.
Example: ArithmeticException,NullPointerException, ArrayIndexOutOfBoundsException etc
Since they are programming error, they can be avoided by nicely/wisely coding. For example "dividing by zero" occurs ArithmeticEceeption. We can avoid them by a simple if condition - if(divisor!=0). Similarly we can avoid NullPointerException by simply checking the references - if(object!=null) or using even better techniques
Error:
Error refers irrecoverable situation that are not being handled by try/catch
Example: OutOfMemoryError, VirtualMachineError, AssertionError etc.
This question may also be helpful in this context - Runtime/Checked/Unchecked/Error-Exception
From the JavaDoc:
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.
RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine.
So, the only difference technically is that they are two different classes. You will only catch both if you declare
catch (Throwable e) { }
But there is a big difference in how they are intended to be used. Unchecked exceptions (RuntimeExceptions) are intended to deal with programming errors and other unexpected problems, but should be caught and handled in the application. Errors are intended to represent problems that the program cannot deal with, such as running out of memory.
Just as checked exceptions are useful for signaling when your methods cannot fulfill their contract, there are other errors outside of your control that can occur that prevent the Java virtual machine from fulfilling its specification, such as when memory is exhausted. Since you can't plan for such errors ahead of time, you would have to catch them everywhere, which defeats the principle of maintaining uncluttered code. Therefore, these errors are unchecked exceptions, meaning exceptions that you don't have to include in a throws clause. You are welcome to catch them (well, some of them), but the compiler won't make you do it.
Unchecked exceptions fall into two categories: those that extend RuntimeException, and those that extend Error. I realize that I said earlier that classes inheriting from class Exception are checked exceptions, but that's only half true: the whole truth is that classes in the Exception hierarchy other than those in the RuntimeException sub-hierarchy are checked exceptions.
Exceptions that extend RuntimeException represent errors that you may want to handle, although you're not required to.
As I stated above, RuntimeExceptions are not checked because making you advertise them would have no effect on establishing the correctness of your methods, and would unnecessarily clutter your otherwise very readable code. Exceptions derived from the Error class, on the other hand, are unchecked because you never want to catch them! Error exceptions are severe errors that require shutting down the virtual machine. InternalError, which I used above, extends VirtualMachineError, which is an Error subclass. OutOfMemoryError is another obvious severe error, but there are others, like StackOverflowError, and various LinkageErrors. A linkage error means something has gone amiss when the class loader tried to load a class for execution, and commonly occurs either because some external source has introduced malicious code in an attempt to circumvent Java's security mechanism, or it came from an out-of-spec byte code generator.
Difference between errors and unchecked exceptions in java?
Unchecked exceptions = class RuntimeException and its subclasses + class Error and its subclasses
There fore the error are part of unchecked exception. Unchecked exception also contains RuntimeException and its subclasses.
The term «reasonable» is relative. As it is, also, the term «application»
As middleware developer, I'm used to deal with unchecked exceptions thrown, or simply ignored, by application developers
What is reasonable to be catched by an application is is a subset of what is reasonable to be catched by its underlying infrastructure (that is, itself, a kind of application)
That's where unchecked exceptions are different from errors. An unchecked can be catched by the infrastructure (i.e. to be registered in a.database) but ignored by an application
Registering an error could be impossible because there could be no JVM to run the registering code (or even the catching code), that's why it's not reasonable to catch them
As an aside, checked exceptions are IMHO overused. Catching them to promote to runtime exceptions is too much usual
Related
I'm trying to understand difference between error and exception but it looks same thing and on Oracle Official tutorials I read this line.
Checked exceptions are subject to the Catch or Specify Requirement.
All exceptions are checked exceptions, except for those indicated by
Error, RuntimeException, and their subclasses.
Now about I'm thinking it's same. But after searching more I found some difference as theoretical that.
Exception: are recoverable
Errors: not recoverable.
Exception Example:
try{
read file
}
catch(FileNotFoundException e){
// how I can recover here? can i create that file?
// I think we can just make log file to continue or exit.
}
Error Example:
try{
try to locate memory
}
catch(MemoryError e){
// I think we can just make log file to continue or exit.
}
Edited
I'm asking about recover-able and non-recoverable.
Error, as you already figured out, means you are in serious trouble. In a catch block you might be able to do something like logging, but basically that's it.
Non-recoverable exceptions are mostly runtime exceptions like NullPointerException. They are usually the result of some missed checks in the program code. Therefore the solution is normally to fix the code.
A recoverable exception is something that you know beforehand can happen and take certain measures. Think of a web application that calls some backend service. That service may or may not be available which can cause the execution of the operation to fail. Therefore you have a checked exception, in this case most likely a custom exception that you throw, and then handle it in the front end code in a manner where you tell the user, sorry backend service xy is down, try again later or contact support.
Recoverable does not mean that the application can do something to resolve the cause of the exception, though there may be cases where this is possible.
All classes that inherit from class Exception but not directly or indirectly from class RuntimeException are considered to be checked exceptions.Such exceptions are typically caused by conditions that are not under the control of the program.
Example
in file processing, the program can’t open a file if it does not
exist.
Recoverable
So It is very easy to know that if a file does not exists so you dont need to open that file hence that is recoverable
All exception types that are direct or indirect subclasses of RuntimeException (package java.lang) are unchecked exceptions. These are typically caused by defects in program’s code.
Example
ArrayIndexOutOfBoundsExceptions
ArithmeticExceptions
Error
Unrecoverable
So thatswhy program can not recover from these kind of errors or exceptions
Unrecoverable errors are the ones that put the application in an undefined state, like a broken database connection or a closed port, you may handle the error and continue to execute but it would not make sense. Modern languages like Rust and Go use the name panic for errors of these nature, to make the distinction clear. Best action to take is logging the error, if it is possible, and exiting the application.
A recoverable errors are the ones we can handle gracefully, like division by zero or validation errors. It is something expected and the resulting behavior is covered in the language spec. Yes, application behaves erratic when that a recoverable error happens but we can contain it or work around it.
The Object Throwable has 2 childs : Exception and Error.
All Exceptions are recoverable and all Errors are non-recoverable.
All Exceptions are recoverable because you can catch them and let your program continue its execution.
However all Errors , even when you add them to a catch block, will cause the abrupt termination of your program.
Examples of Errors: StackOverflowError, OutOfMemoryError,..
Remark : Checked and unchecked Exceptions are childs of Exception so recoverable.
Checked exceptions need to be caught or declared to be thrown at compilation time but runtimeexceptions need not ...why we give important only to checked exception ...
In Java, the original inventors of the language wanted to distinguish between common types of exceptions, which may occur in a program. They came up with these three types:
Checked exceptions are used for errors, which may occur at run-time and are expected (sort of), for example, IOException. When doing file or network I/O, for example, an error may occur at any time (disk full, connection lost, etc.) The programmer has to be aware, that any operation called may fail at any time, and thus, the language enforces this kind of awareness by forcing the programmer to do something about the exception.
Unchecked exceptions are used for programming errors, such as NullPointerException, IllegalArgumentException, etc. These errors are usually the result of an oversight of the programmer, and constitute bugs in the program. They should not be handled by most parts of the code, as all guarantees about the state, the program is currently in and its consistency, are gone. One of the distiguishing features of a run-time exception is, that it is unexpected (you don't really expect there to be a bug in your program, right? -- except on the general level of "of course, I would not bet my life on this program being bug-free")
Errors, from which a recovery is hardly possible, such as OutOfMemoryError, AssertionError, etc. These exceptions are the really bad ones. These guys are usually never handled, and if they occur, will cause the program to crash.
Of course, in practice, many application will handle run-time exceptions (at least by logging them), and even Errors. And frameworks like Spring tend to blur the distinction further by making all exceptions unchecked (i.e., run-time exceptions) anyway. Interestingly, checked exceptions were considered for inclusion in C# and omitted, because they add a heavy burden on the programmer. Opinions vary on that topic, even today.
Taken from http://en.wikipedia.org/wiki/Exception_handling
Unchecked exception types should not
be handled except, with consideration,
at the outermost levels of scope.
These often represent scenarios that
do not allow for recovery:
RuntimeExceptions frequently reflect
programming defects,[19] and Errors
generally represent unrecoverable JVM
failures. The view is that, even in a
language that supports checked
exceptions, there are cases where the
use of checked exceptions is not
appropriate
Clearly mentions that it represents scenarios that do not allow for recovery
The division gives you flexibility: when thinking what kind of exceptions to throw, you should throw checked exceptions only when the application can reasonably recover from them (for example: "can't write file" is rarely a good reason to crash; rather, let's show a message to the user). Runtime exceptions are supposed to be fatal (programming errors), so it's better to let the program crash right away.
It was supposed to be a good idea. But it's just too complex in practice. The core problem is that the library and language designers are supposed to decide what kind of errors are fatal to an application (which doesn't even exist at that time!).
Did you know that while 1 / 0 results in ArithmeticException, 1.0 / 0 is a perfectly legal Infinity? Obvious - or not... And java.text.Format is supposed to convert an arbitrary object to String, but for some reason it throws an unchecked exception (IllegalArgumentException) if the object to be converted is somehow wrong type (e.g. null), so in practice you must remember to write a try-catch block whenever you use Format. Obviously someone thinks that converting nulls to strings is a fatal programming error. I would rather return an empty string. Your mileage may vary. The JDK is full of this kind of weird choices, and it clearly shows the problem of choosing between checked vs. unchecked.
This problem has made many people advocate unchecked exceptions only. I think it's just silly; most exceptions should be taken care of, because they signal something important. If I was a language designer, I would make all exceptions checked, but instead of a try-catch -block, one could use a plain annotation to say "I don't care about this exception" (which essentially would convert that checked exception into a runtime exception). This would give the benefits of checked exceptions (nothing goes unnoticed unless explicitly told so) AND the benefits of unchecked exceptions (no heavy try-catch blocks all around). It would be the application programmer's call to decide what's fatal and what's expected.
Of course, you can catch runtime exceptions if you want to. A plain catch(Exception ex) does it.
Look at the name of the exception "RunTime".
At compile time the compiler can see exactly what and where things can go wrong with most of your code.
However some objects/values can only be evaluated at run-time and unfortunately the compiler cannot foresee this.
e.g. casting an object to int, when it is in fact a string. You can only determine it at run-time. Thus a run-time exception will be thrown
Have a look at the common RuntimeExceptions:
ArithmeticException
ArrayIndexOutOfBoundsException
ClassCastException
EmptyStackException
IllegalArgumentException
IllegalMonitorStateException
NullPointerException
UnsupportedOperationException
Practically speaking: Most of those exceptions can occure everywhere and are most likely a programmers error, and as such are only needed to be handled in some kind of bug reporting handler. Other Exceptions show problems with the environment of the JVM, and need to be handled, because they cannot be guaranteed no to be thrown be the program alone.
if exception occurred at runtime then immediately JVM creates exception object and that object message is printed on console.
unchecked exceptions are occurred due to poor logic of our program.so program will be terminated abnormally.but JVM will not be halted.so JVM creates Excpetion object.
if we consider checked exceptions,for example,if we want to load some external file into our program , JVM is responsible for that.so,if any problems are occurred while that file is loading then JVM will be halted .so,then who creates exception object.this is the problem with checked excpetions .
to over come above problem we have to handle checked excptions at compiletime using throws keyword.
if you handle checked exception the following is done
-- JVM executes one by one statement , when it identifies throws keyword followed by checked exception then it creates checked exception object.so,when the exception is occurred then already created exception object is used to print the exception information on the console.
When you can handle the recovery of the state of Object , go for Checked Exception.
When you cannot handle the recovery go for UnCheckedException.
Mostly API developers go for Runtime Exception ,
they do not want to enforce handling exception by the user,
since they themselves do not know how to handle it
Runtime exceptions can occur anywhere in a program, and in a typical one they can be very numerous. Having to add runtime exceptions in every method declaration would reduce a program's clarity. Thus, the compiler does not require that you catch or specify runtime exceptions (although you can).
Are there any guidelines on exception propagation in Java?
When do you add an exception to the method signature?
For example: if an exception is only thrown when an essential program resource is missing, and can only be handled at the top level, do I propagate it through all methods using this exception through all the methods using the erring method?
Are there any good practices? Any bad practices?
I'm sorry if I'm being vague, but I'm just looking for some (general) advice on programming style concerning exceptions.
Guidelines that have helped me in the past include:
Throw exceptions when the method cannot handle the exception, and more importantly, should be handled by the caller. A good example of this happens to present in the Servlet API - doGet() and doPost() throw ServletException or IOException in certain circumstances where the request could not be read correctly. Neither of these methods are in a position to handle the exception, but the container is (which results in the 50x error page in most cases).
Bubble the exception if the method cannot handle it. This is a corollary of the above, but applicable to methods that must catch the exception. If the caught exception cannot be handled correctly by the method, then it is preferable to bubble it.
Throw the exception right away. This might sound vague, but if an exception scenario is encountered, then it is a good practice to throw an exception indicating the original point of failure, instead of attempting to handle the failure via error codes, until a point deemed suitable for throwing the exception. In other words, attempt to minimize mixing exception handling with error handling.
Either log the exception or bubble it, but don't do both. Logging an exception often indicates that the exception stack has been completely unwound, indicating that no further bubbling of the exception has occurred. Hence, it is not recommended to do both at the same time, as it often leads to a frustrating experience in debugging.
Use subclasses of java.lang.Exception (checked exceptions), when you except the caller to handle the exception. This results in the compiler throwing an error message if the caller does not handle the exception. Beware though, this usually results in developers "swallowing" exceptions in code.
Use subclasses of java.lang.RuntimeException (unchecked exceptions) to signal programming errors. The exception classes that are recommended here include IllegalStateException, IllegalArgumentException, UnsupportedOperationException etc. Again, one must be careful about using exception classes like NullPointerException (almost always a bad practice to throw one).
Use exception class hierarchies for communicating information about exceptions across various tiers. By implementing a hierarchy, you could generalize the exception handling behavior in the caller. For example, you could use a root exception like DomainException which has several subclasses like InvalidCustomerException, InvalidProductException etc. The caveat here is that your exception hierarchy can explode very quickly if you represent each separate exceptional scenario as a separate exception.
Avoid catching exceptions you cannot handle. Pretty obvious, but a lot of developers attempt to catch java.lang.Exception or java.lang.Throwable. Since all subclassed exceptions can be caught, the runtime behavior of the application can often be vague when "global" exception classes are caught. After all, one wouldn't want to catch OutOfMemoryError - how should one handle such an exception?
Wrap exceptions with care. Rethrowing an exception resets the exception stack. Unless the original cause has been provided to the new exception object, it is lost forever. In order to preserve the exception stack, one will have to provide the original exception object to the new exception's constructor.
Convert checked exceptions into unchecked ones only when required. When wrapping an exception, it is possible to wrap a checked exception and throw an unchecked one. This is useful in certain cases, especially when the intention is to abort the currently executing thread. However, in other scenarios this can cause a bit of pain, for the compiler checks are not performed. Therefore, adapting a checked exception as an unchecked one is not meant to be done blindly.
You should handle the method as soon as possible, but it must make sense. If the exception doesn't make sense to be thrown by your method, but you can't handle it, wrap it into another exception and throw this new exception.
A bad practice about exception is to catch them all (it's not pokemon, it's java !) so avoid catch(Exception e) or worse catch(Throwable t).
I would like to handle errors with (unchecked) exceptions. I heared that for each kind of exception I should create a subclass of either Error or RuntimeException.
What's the difference?
Errors should identify programmatically unrecoverable problems (e.g. out of memory). Exceptions should identify programmatically recoverable problems which are caused by unexpected conditions outside control of code (e.g. database down). RuntimeExceptions should identify programmatically recoverable problems which are caused by faults in code flow (read: developer's faults such as null pointer, illegal argument, etc).
In your case you want to inherit from RuntimeException.
I think the JavaDocs kind of say it all:
An Error is a subclass of
Throwable * that
indicates serious problems that a
reasonable application * should not
try to catch. Most such errors are
abnormal conditions. * The
ThreadDeath error, though
a "normal" condition, * is also a
subclass of Error because
most applications * should not try to
catch it.
These are things like stackoverflow, out of memory... you want to extend RuntimeException.
RuntimeException is a special kind of Exception, Exceptions that compiler will not catch. Error is something that is thrown when there is some severe system problem. There is not a close relation between Error and RuntimeException. Yours seem closer to RuntimeException.
Always use RuntimeException--I've virtually never seen a case for Error.
I've heard the same thing about creating your own exception though and I don't really understand it. Often it's useful, but I use InvalidArgumentException ALL THE TIME.
I'm trying to learn more about basic Java and the different types of Throwables, can someone let me know the differences between Exceptions and Errors?
Errors should not be caught or handled (except in the rarest of cases). Exceptions are the bread and butter of exception handling. The Javadoc explains it well:
An Error is a subclass of Throwable that indicates serious problems that a
reasonable application should not try to catch. Most such errors are abnormal
conditions.
Look at a few of the subclasses of Error, taking some of their JavaDoc comments:
AnnotationFormatError - Thrown when the annotation parser attempts to read an annotation from a class file and determines that the annotation is malformed.
AssertionError - Thrown to indicate that an assertion has failed.
LinkageError - Subclasses of LinkageError indicate that a class has some dependency on another class; however, the latter class has incompatibly changed after the compilation of the former class.
VirtualMachineError - Thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating.
There are really three important subcategories of Throwable:
Error - Something severe enough has gone wrong the most applications should crash rather than try to handle the problem,
Unchecked Exception (aka RuntimeException) - Very often a programming error such as a NullPointerException or an illegal argument. Applications can sometimes handle or recover from this Throwable category -- or at least catch it at the Thread's run() method, log the complaint, and continue running.
Checked Exception (aka Everything else) - Applications are expected to be able to catch and meaningfully do something with the rest, such as FileNotFoundException and TimeoutException...
This slide showing Java's exception hierarchy by #georgios-gousios concisely explains the differences between Errors and Exceptions in Java.
Errors tend to signal the end of your application as you know it. It typically cannot be recovered from and should cause your VM to exit. Catching them should not be done except to possibly log or display and appropriate message before exiting.
Example:
OutOfMemoryError - Not much you can do as your program can no longer run.
Exceptions are often recoverable and even when not, they generally just mean an attempted operation failed, but your program can still carry on.
Example:
IllegalArgumentException - Passed invalid data to a method so that method call failed, but it does not affect future operations.
These are simplistic examples, and there is another wealth of information on just Exceptions alone.
Errors -
Errors in java are of type java.lang.Error.
All errors in java are unchecked type.
Errors happen at run time. They will not be known to compiler.
It is impossible to recover from errors.
Errors are mostly caused by the environment in which application is running.
Examples : java.lang.StackOverflowError, java.lang.OutOfMemoryError
Exceptions -
Exceptions in java are of type java.lang.Exception.
Exceptions include both checked as well as unchecked type.
Checked exceptions are known to compiler where as unchecked exceptions are not known to compiler because they occur at run time.
You can recover from exceptions by handling them through try-catch blocks.
Exceptions are mainly caused by the application itself.
Examples : Checked Exceptions : SQLException, IOException
Unchecked Exceptions : ArrayIndexOutOfBoundException, ClassCastException, NullPointerException
further reading : http://javaconceptoftheday.com/difference-between-error-vs-exception-in-java/
Sun puts it best:
An Error is a subclass of Throwable
that indicates serious problems that a
reasonable application should not try
to catch.
The description of the Error class is quite clear:
An Error is a subclass of Throwable
that indicates serious problems that a
reasonable application should not try
to catch. Most such errors are
abnormal conditions. The ThreadDeath
error, though a "normal" condition, is
also a subclass of Error because most
applications should not try to catch
it.
A method is not required to declare in
its throws clause any subclasses of
Error that might be thrown during the
execution of the method but not
caught, since these errors are
abnormal conditions that should never
occur.
Cited from Java's own documentation of the class Error.
In short, you should not catch Errors, except you have a good reason to do so. (For example to prevent your implementation of web server to crash if a servlet runs out of memory or something like that.)
An Exception, on the other hand, is just a normal exception as in any other modern language. You will find a detailed description in the Java API documentation or any online or offline resource.
There is several similarities and differences between classes java.lang.Exception and java.lang.Error.
Similarities:
First - both classes extends java.lang.Throwable and as a result
inherits many of the methods which are common to be used when dealing
with errors such as: getMessage, getStackTrace, printStackTrace and
so on.
Second, as being subclasses of java.lang.Throwable they both inherit
following properties:
Throwable itself and any of its subclasses (including java.lang.Error) can be declared in method exceptions list using throws keyword. Such declaration required only for java.lang.Exception and subclasses, for java.lang.Throwable, java.lang.Error and java.lang.RuntimeException and their subclasses it is optional.
Only java.lang.Throwable and subclasses allowed to be used in the catch clause.
Only java.lang.Throwable and subclasses can be used with keyword - throw.
The conclusion from this property is following both java.lang.Error and java.lang.Exception can be declared in the method header, can be in catch clause, can be used with keyword throw.
Differences:
First - conceptual difference: java.lang.Error designed to be
thrown by the JVM and indicate serious problems and intended to stop
program execution instead of being caught(but it is possible as for
any other java.lang.Throwable successor).
A passage from javadoc description about java.lang.Error:
...indicates serious problems that a reasonable application should
not try to catch.
In opposite java.lang.Exception designed to represent errors that
expected and can be handled by a programmer without terminating
program execution.
A passage from javadoc description about java.lang.Exception:
...indicates conditions that a reasonable application might want to
catch.
The second difference between java.lang.Error and java.lang.Exception that first considered to be a unchecked exception for compile-time exception checking. As the result code throwing java.lang.Error or its subclasses don't require to declare this error in the method header. While throwing java.lang.Exception required declaration in the method header.
Throwable and its successor class diagram (properties and methods are omitted).
IMO an error is something that can cause your application to fail and should not be handled. An exception is something that can cause unpredictable results, but can be recovered from.
Example:
If a program has run out of memory it is an error as the application cannot continue. However, if a program accepts an incorrect input type it is an exception as the program can handle it and redirect to receive the correct input type.
Errors are mainly caused by the environment in which application is running. For example, OutOfMemoryError occurs when JVM runs out of memory or StackOverflowError occurs when stack overflows.
Exceptions are mainly caused by the application itself. For example, NullPointerException occurs when an application tries to access null object or ClassCastException occurs when an application tries to cast incompatible class types.
Source : Difference Between Error Vs Exception In Java
Here's a pretty good summary from Java API what an Error and Exception represents:
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.
A method is not required to declare in
its throws clause any subclasses of
Error that might be thrown during the
execution of the method but not
caught, since these errors are
abnormal conditions that should never
occur.
OTOH, for Exceptions, Java API says:
The class Exception and its subclasses are a form of Throwable that indicates conditions that a reasonable application might want to catch.
Errors are caused by the environment where your application or program runs. Most times, you may not recover from it as this ends your application or program. Javadoc advised that you shouldn't bother catching such errors since the environment e.g. JVM, on such errors is going to quit anyway.
Examples:
VirtualMachineError - Thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating.
OutOfMemoryError occurs when JVM runs out of memory or
StackOverflowError occurs when stack runs over.
Exceptions are caused by your application or program itself; maybe due to your own mistake. Most times you can recover from it and your application would still continue to run. You are advised to catch such errors to prevent abnormal termination of your application or program and/or to be able to customize the exception message so the users see a nicely formatted message instead of the default ugly exception messages scattered all over the place.
Examples:
NullPointerException occurs when an application tries to access null object. or
Trying to access an array with a non-existing index or calling a function with wrong data or parameters.