In general it's good to avoid words like "handle" or "process" as part of routine names and class names, unless you are dealing with (e.g.) file handles or (e.g.) unix processes. However abstract classes often don't really know what they're going to do with something besides, say, process it. In my current situation I have an "EmailProcessor" that logs into a user's inbox and processes messages from it. It's not really clear to me how to give this a more precise name, although I've noticed the following style matter arises:

• better to treat derived classes as clients and named the base class by the part of the functionality it implements? Gives it more meaning but will violate is-a. E.g. EmailAcquirer would be a reasonable name since it's acquiring for the derived class, but the derived class won't be acquiring for anyone.
• Or just really vague name since who knows what the derived classes will do. However "Processor" is still too general since it's doing many relevant operations, like logging in and using IMAP.

Any way out of this dilemma?

Problem is more evident for abstract methods, in which you can't really answer the question "what does this do?" because the answer is simply "whatever the client wants."