PIC: kbhit() vs INT_RDA to detect received data in CCS PIC C?

When receiving data on the ESUART of the PIC one may either poll using kbhit or enable the ISR called INT_RDS in CCS PIC C and wait for it to be fired. Then one can use getc() and store the result into a variable and wait for the next character.

I usually see kbhit() being used.

(1) Which approach is suited for which scenario? What approach is unsuitable for which scenario?

Besides this, I have few other questions. The manual of CCS PIC C states:

INT_RDA Interrupt fires when the receive data available
INT_TBE Interrupt fires when the transmit data empty

(2) While I understand the concept of INT_RDA and assume that it is fired for everytime a character is received, is it?
(3) As far as I understand if we do read input characters, the buffer will store upto 3 characters and once the third character is received, a bit shall be set that specifies buffer overrun. After this the 4th input bit shall be lost. is this correct?
(4) Why is there no interrupt for buffer overflow?? That makes no sense.
(5) What is the point of a transmit empty buffer? How big is the transmit empty buffer? When we want to transmit data we just write putc() or printf(). This makes transmit empty buffer appear strange.

I am not a PIC programmer but I can answer the question no 5. Polling is a blocking algorithm. The micro cant do anything else (except interrupts). So there is no point to wait for transmition to complete. You just write what you need to transfer to the software buffer and continue doing another tasks. Interrupt routine will be called when is possible to transfer another byte.

Statements like "that makes no sense" suggest that you didn't yet think thoroughly about the problem. If you study some application examples, you'll better unterstand the concepts behind PIC24 UART design and common interrupt handling schemes.

If you have detail questions, I'm willing to help.

- - - Updated - - -

Forgot to mention that a receiver overrun triggers the UART error interrupt. But it's no so often used.

I read the PIC18F87K22 datasheet and CCS PIC C user manual. After that I posted this question. I assumed that the EUSART of all the PICs works in the same way i.e it is basially the same block. Are you saying that the PIC24 UART datasheet will help me understand these things? Anything you tell me to read I will read it if it will help me understand this stuff.

This gets back to what you are actually trying to do that makes you think the solution is one of the options above.
It sounds like you are trying to read a character from a EUSART so you can process it.
If you can afford to block until you receive the character, then wait until the RCxIF bit is set (don't set the RCxIE bit as part of the setup) and then simply read the character from the RCREGx register and carry on to process it. Part of that processing could be to check the FERR and OERR bits but if you can afford to block then probably the characters are coming in slow enough for you to process each one without getting these errors.
If you cannot afford to block, then define an ISR and configure the EUSART appropriately (i.e. high or low priority or whatever) and in the ISR you read the character from the RCREGx to a buffer and perhaps set some flag to show that the buffer contains characters. You can also check for the FERR and OERR bits but ISRs are generally called fast enough that the OERR shoudl not be set and you have other problems if you get FERR. In the main loop you can detect when you have characters in the buffer to process and handle them as you can.
The data sheet shows all of these bits and describes how they work. Section 22.2.2 explains how to receive characters.
The thing here is to treat the reception of a character as a single action. Also a peripherla such as the EUSART is rather straight forward that it is much easier to simply deal directly with it rather than hiding it behind library funciotns that you may or may not undersntad how they work.
Susan