The answer to your question is: it depends. What you are currently doing is called exception suppression, that is calling a method which may throw and returning false when it indeed happens. Is it a good practice? That is difficult to answer without knowing exactly what you want from the method where you are suppressing the exception.
I personally have completely given up on suppressing exceptions just for the sake of returning false when an exception is thrown and build my code knowing that, but sometimes having a method which is exception safe might be a good idea.
I have found out having a method throw different kind of exceptions is good when you want to process each given exception type differently, such as one means internal server error while the other may simply indicate a user is not authorized to perform certain action. Then the api of the method are not only its parameters and return values but also the exceptions the method throws.
With error suppression and returning false always, you have no option to distinguish the internal error of the method, because it is all hidden behind one return value, false. That does not necessarily mean that it is not a valid design.
All in all, if all you want is to know whether an operation was successful or not, suppressing an exception and returning a bool flag might be a good idea, if you however want the system to react differently to different exceptions, you are much better off with the method throwing, you consuming the exceptions and dispatching events as reactions to them.