Function modules can return an error code which will populate the value of SY-SUBRC, much like many statements will do (READ TABLE, SELECT * FROM ... and even after ENDLOOP). The exception handling usually goes hand-in-hand with
T100 messages, so the exception is raised against a message which will be available/accessible via the SY-MSG* variables. As abap developer you can chose to ignore exceptions, by simply skip checking the SY-SUBRC value after your module call. A bad habbit, because it does not show whether it was a choice, or whether it was left out accidentally.
It's good custom to remove all exceptions except OTHERS, set it to e.g. 4 (OTHERS = 4.) if you want to respond to problems (more detail on the actual problem will be available in system message fields). Set it to 0: OTHERS = 0. if you specifically don't care about the function's response. This clearly shows the decision: "we are not interested".
Surely you have seen that when a function module throws an exception and your Abap does not respond to it - the report will cause a dump. Using the OTHERS = 4 in your exceptions block will cater for this, as it will catch all uncaught exceptions.
Another quite interesting matter: what if your function module throws and error message, without raising an exception for it ? Your program will be stopped with the error message. Or, in case of module pools, the error will freeze the screen. You can automatically assign error messages which have no exceptions assigned to them to exception ERROR_MESSAGE. This exception is (much like OTHERS) a predefined name. Could come in handy !