Although, I have posted the answer in se.stackexchange site, that might be still helpful to post here.

Assertions are used,

1. When you want to stop the program immediately rather to proceed with an unwanted state. This is often related to the philosophy of the Fail-fast ^{[ 1 ]} system design.

2. When there are certain possibilities of cascading failures (i.e. in microservices) for the first unexpected condition that might lead the application into severe inconsistent or unrecoverable states.

3. When you want to detect bugs in your system exclusively in the debugging period. You might want to disable them in production if language supports.

4. When you already know that the unexpected conditions arose due to your internal miss-implementation and external system (i.e the callers) has no control over the unwanted state.

Exceptions are used,

1. When you know that the unexpected conditions arose due to external systems fault (i.e. wrong parameters, lack of resources etc).

2. When you know that the conditions can be backed up with alternative paths keeping the application functional qualities still intact (i.e. might work well for another call with proper parameters from the caller or external system).

3. When you want to log and let the developers know about some unwanted state but not a big deal.

Note: “The more you use assertions, the more robust system you get”. In contrast “The more you use exceptions and handle them, the more resilient system you get“.

^{[ 1 ] Fail fast - In systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process. Such designs often check the system's state at several points in an operation, so any failures can be detected early. The responsibility of a fail-fast module is detecting errors, then letting the next-highest level of the system handle them.}

Assertion and Exception Handling both can assure programme correctness and avoid logic error,

but assertion can enable and disable as programmer wish,

in compiler if you use "java -ea JavaFileName" or "java -enableasserations JavaFileName" you can compile with assertion

if programmers don't need it ,"java -da JavaFileName " or "java -disableasserations JavaFileName " they can disable assertion.

this facility not in Exception handling

Use exceptions for conditions you expect to occur, and user assertions for conditions that should never occur.

Usually, in a real-world project, you want exceptions to cover the conditions that should never happen and prevent the assertion from becoming true. After all, you want the program to operate and never get into that invalid state, so you should use exceptions and other techniques to ensure that the program never gets into such state. Sometimes, however, there are multiple ways that an assertion becomes true and you can anticipate at the time only few of them. So having these "hard-constraints" through assertions ensures that if in the future the program is in an invalid state that you haven't anticipated and that it shouldn't happen it will stop and you will have to investigate how this happened.

In other words, exceptions checks for invalid input data while assertions act as a mechanism for detecting bugs in your code.