It sounds as if you're building an interface that performs one of several distinct operations with each invocation. I'm not sure if you're referring to a "command-line" application (which does one action, then exits) or a CLI application (which displays a prompt and responds repeatedly to user input). In general, the former will be much simpler to build than the latter; I think it only makes sense to use a CLI if your application requires some persistent state that evolves over multiple commands. If you are tackling something like this, then alphazero is correct -- you should probably learn about REPLs and copy a good one.
In any case, the operation performed will depend on the arguments passed on the command-line, so I'll brainstorm about that part...
It's sensible think of the application as a set of distinct "Command" objects, one for each type of operation. The entry-point to the application should thus be a some sort of CommandLineDispatcher object that dispatches requests to the appropriate Command object.
To be modular, the dispatcher should be configured with an abstracted mapping (eg, a Hashtable) to associate each command token (usually the first word of the command-line string) to the Command object that handles it. The dispatcher may also handle common options-parsing, probably using some off-the-shelf "getopts" library to do the heavy lifting.
To start simple, each Command object could implement a consistent interface for doing its work; maybe something like this:
public void execute(List<String> args)
This way, the entry-point dispatcher just finds the Command being requested, and executes it.
Regarding error-handling: the execute() method might just throw an exception to communicate errors... Exception could be caught and processed by the dispatcher, or simply logged to the screen. Alternatively, failing Commands could invoke some shared usage function to combine an error message with general instructions. I don't think the "entry point" should necessarily be made aware of problems as you suggest; if you need robust error-handling (eg, for logging or alerting capabilities), this seems like it belongs in a separate component that could be provided to the Command object.
In general, a command-line application is no different than any other application that responds to user input -- you'll need a dispatcher to parse and route the input, and handlers (aka "controllers") to execute the supported operations. If you need other services (logging, alerting, database connectivity, etc), you'll do well to create separate components to isolate this logic and expose it with clean interfaces.