I know both error_logger and error_logger_tty_h are swappable handlers of gen_event error_logger.
From their source code, I know error_logger report messages ending up erlang:display, and error_logger_tty_h ending up `io:format(user, String, Args)
What I feel confused is, what difference between error_logger and error_logger_tty_h for purposes?
This is mostly documented in http://erlang.org/doc/man/error_logger.html, but basically, the error_logger module implements the API for starting and interacting with the gen_event server or "event manager" which is also named error_logger. This process will receive the events and pass them to the registered handlers. The API module includes functions like error_msg(...) for sending the actual event messages in the correct format expected by the server.
However - the error_logger module also implements gen_event callback functions so that it can be registered as a handler for the server. This code could (and perhaps should) have been placed in a separate module, but the advantage is that it is trivially known that the callback code is already loaded when the error logger starts.
The error logger is started by the Erlang boot script, before any application - including the kernel app - has been started. At that time, very little is known about the capabilities of the system, but basic error logging still needs to work. The callbacks in the error_logger module implement primitive logging that print any errors during this early phase straight to the stdout of the Beam runtime process - which might just be to a console or /dev/null. It also buffers up to a fixed number of messages to be passed on to a better handler later on.
When the kernel application starts, it will read the kernel app environment settings and swap the error_logger handler to the kind you really want for the system, such as error_logger_tty_h or error_logger_file_h. It will also get any buffered messages from the old logger when it takes over, so it can handle them properly.
That's not quite the end of the story, though, because the error_logger module will still be registered as a handler for the event manager. In this new role it doesn't do any printing or buffering, but it is responsible for forwarding any events to the Erlang node corresponding to the group leader process of the process that dispatched the event. This ensures that error logger events always make their way "home" to be logged on the node of their group leader process.