I've been learning Java lately and had some great feedback from the previous threads (hangman and guess a number games).
I was challenged by a user to try to get this code done, so I'm posting it here for further review.
Basically my weakeast (among many) points are exception handling and proper documentation.
What do you think about it? How would you improve it?

This class only does one thing. You could read the file somewhere else and create a RandomStringPicker class from the lines you read. But now you can reuse this class for other purposes too, for example in unit tests.

This implementation also improves the weakness of your init method. If you forget to call init, your program will compile, but not work. In the example above there is no such uncertainty: if the class is not constructed with a list, it will not compile.

Or you could even go one step further and make the class work with anything, not only strings:

Bugs

If you have 10 lines, the call getRandomNumber(1, lines.size()) will return a random number between 1 and 10, inclusive, which has two problems:

The first line (index = 0) will never be picked

If 10 is picked, that will be beyond the end of your list and throw an exception

Related to this issue is that you don't really need a minimum parameter for your random number picker. So that's an unnecessary detail in your implementation, you could use something more simple like the example above.

Printing, validating and logging

It's not good practice to print things on the console. If you want to verify your code works, write unit tests. If you want to log messages during runtime, use a logger.

Exception Handling
You wrap the readAllLines with a try catch block, but if an error occurs, you simply write a line to the console, and continue... in the very next line you call line.size(), which will result in a NullPointerException...
Morale of the story is - if you don't have anything smart to do in your catch block - it is better to let the exception bubble up to where it can be handled, or otherwise stop the application completely, notifying the user what exactly was the problems (that's what exceptions are for...)

Documentation
The only documentation you have is for the getRandomNumber(int min, int max) method, and it is full of reiterations on how this methods returns a random number between a min and a max number.
This kind of documentation does not help anyone - the signature of the method is self-explanatory. Documentation has a nasty habit of rotting - since you tend not to maintain it as you maintain the code, and it becomes inaccurate and ultimately misleading.

Documentation would be needed when the method's signature does not convey what the method is doing (like in init), but I would sooner change the name (and the content) of the method before writing documentation, as suggested in the other answer here, since I believe that comments are a code-smell, and that self-explanatory code is an indicator for better design.

Files can be arbitrarily large. Larger than what can actually fit in your VM's memory. Your algorithm, while simple, does not deal well with a source of numbers of which the size is not known at the start.

So lets devise a better algorithm that can deal with an arbitrarily large number of inputs, of which we do not know the size beforehand.

To abstract this we will act as if our function gets as input an Iterator<T> (it could be one that reads from a file, or simply iterates a list, or reads primes from a webservice, ...)

First off, we'll need to handle the case that the Iterator is empty. Your current solution simply throws an IndexOutOfBoundsException, but we can do better, and we'll throw a custom exception.

The idea of the algorithm is that we have a current choice, and for each new input we may take it as our current choice instead. Of course, the odds that we should change our current choice should decrease proportionally to the number of inputs we've seen.

We'll need to keep track of a few things :

the item we would have picked if we'd have seen all inputs : currentPick

the number of inputs we've seen so far : totalInputs

When we read the first number it's the only one we can pick so far, so currentPick becomes that number and we increase totalInputs.

Then for every next input, we determine the chance that that number becomes our currentPick, and that chance is 1/totalInputs. So we ask our random source to get the next int in [0, totalInputs[ and if it turns out to be 0, we change our currentPick to the latest item.