While it's true that what happens during a buffer overflow has a lot to do with the development context in which the overflow occurs (ie, what language, what operating system, and even what type of hardware) - it's also a general good practice to check the size and syntax.
I'd be impressed if anyone has both the time to do a write up for each of the languages you mention... I know the vagaries of some of these languages, but not all of them - to really adequately hit all of them in a single answer would be quite an impressive level of expertise.
I can say for a managed language - like Java and (I believe --- no my forte) .Net - you are looking at (generally) less terrifying ramifications than in a language closer to the bare metal (C, C++). A buffer overflow in a language with managed memory should allow the program to allocate the memory as the information arrives and handle it in a somewhat eloquent fashion (to a point!). The truly classic overflow is one where the programmer has not allocated his character array properly and the data in the overflow has leaked into another segment of the program.
That said - even in Java a buffer overflow can cause unintended responses. In a managed language, it could be that you suck the process dry of allocated memory causing slowdowns. You could cause the machine to "fail open" if it hasn't been properly configured, you could produce unexpected output in whatever data persistence mechanism the program is using. All of this is true regardless of the language.
A general size check at the front lines is simply good programming practice. Why not bounce bad data before you work harder at it? You're saving CPU cycles, runtime and persistent memory, and you're protecting the back end. Layered security is just a good way to go.