Exception

An exception is a signal (an exceptional event) that indicates the occurrence of an

abnormal condition/problem during the execution of the program and it changes the
normal flow of the program execution

---

It is –

an abnormal condition that occurs during the execution of the program and
changes the normal flow of the program execution

Exception handling

It is a mechanism to handle the occurrence of exceptions

Exceptions are caught by the exception handlers (catchers).

An exception need not be caught in the same context.

Errors are used to represent those conditions which occur outside the application,
such as crash of the system. Runtime exceptions are usually occur by fault in the
application logic. You can't do anything in these situations. When runtime exception
occur, you have to re-write your program code. So, these are not checked by
compiler. These runtime exceptions will uncover in development, and testing
period. Then we have to refactor our code to remove these errors.

Unchecked Exceptions

Are the exceptions that cannot be dealt with

Are not checked by the compiler

a method is not obliged to establish a policy for the unchecked exceptions thrown
by its implementation (and they almost always do not do so)

Checked Exceptions

Are the exceptions that must be dealt with as they are checked by the compiler

a method is obliged to establish a policy for all the checked exceptions thrown by its
implementation (either pass the checked exception further up the stack, or handle
it somehow)
Memory leak

Memory leak occurs when a program consumes memory but is unable to (or does
not) release it back to the operating system

A memory leak can diminish the performance of the computer by reducing the
amount of available memory

class Exception - is intended for abnormal conditions and borken contracts

class Error - is intended for

checked exceptions are class Exception and its subclasses, excluding class
RuntimeException and its subclasses

checked exceptions = class Exception and its subclasses - class RuntimeException

and its subclasses

unchecked exceptions are class RuntimeException and its subclasses and class
Error and its subclasses

unchecked exceptions = class RuntimeException and its subclasses + class Error

and its subclasses

checked exceptions were introduced based on the assumption that -

if the compiler forces the programmer to either handle the exception or pass
it on in an exception specification, then the programmer's attention will always be
brought back to the possibility of errors and they will thus properly take care of
them.
but the problem is, in most of the cases, it is having opposite effect than what was
intended

when someone is trying to do something and you are constantly prodding them with
annoyances, they will use the quickest device available to make those annoyances
go away so they can get their thing done, perhaps assuming they'll go back and
take out the device later.

prodding => Poke (someone) with a finger, foot, or pointed objec

ream => large quantity of written matter; "he wrote reams and reams"

drawbacks of checked exceptions:

================================

make code much less readable

there is growing perception that checked exceptions encourage people to make

them vanish/disappear

throw and throws are both keywords

throw => the throw keyword is used to manually throw an exception

a statement containing throw keyword is called "throw statement"

throws =>
can we throw an Error(an object of class Error)?.......Yes

package com.learn;

public class ExceptionTester {

public static void main(String args[]) {

throw new Error("test");

output

==========

Exception in thread "main" java.lang.Error: test

at com.learn.ExceptionTester.main(ExceptionTester.java:5)

can we catch and handle an Error?.........Yes

package com.learn;

public class ExceptionTester {

public static void main(String args[]) {

try {

throw new Error("test");

catch(Error e) {
 System.out.println(e.getMessage());

output

==========

test

how can we identify whether an exception is checked or unchecked at run-time?

To know at run-time if you have a checked exception (though why it could possibly
matter I don't know), we could use:

if(throwable instanceof Exception and !(throwable instanceof RuntimeException)) {

// this is a checked exception - i.e. not an Error or RuntimeException

If a method can throw a checked exception, it must be specified as part of its

method signature

If a method can throw an unchecked exception, it need not be specified as part of

its method signature (Note: it can be specified as part of its method signature)

Note: there is nothing that you can do with checked exception; but cannot do with
unchecked exceptions

package com.yubico;
public class MyRuntimeException extends RuntimeException {

public MyRuntimeException(String message) {

super(message);

--

package com.yubico;

public class ExceptionTester {

public static void main(String args[]) {

try {

new ExceptionTester().test();

catch(Exception e) {

System.out.println(e.getMessage());

public void test() throws MyRuntimeException {

throw new MyRuntimeException("my runtime exception message");

output
"my runtime exception message"

The rule says that you can override/implement a method, but you cannot declare
additional exception to those declared by the original method signature.

ping - to determine whether the destination machine is reachable or not

nslookup - to query DNS to obtain domain name or ip mapping or to find any other
specific dns record

tracert - to find the route path and transit times of packets to destination machine
(across an ip network)

zip - data compression and archiving tool