"In your example, I'd say the overly long name comes from an overly narrow functionality. For something that specific, you should use a description string." - What use is a description string when you're staring at a code listing, trying to figure out what it does?

"a good IDE let you manage and tolerate higher levels of complexity." - Which is a good thing.

"You'll also be less encouraged to simplify your code." - Simplifying code is a discipline that can just as easily be avoided by people writing in Notepad. Simpler code comes with experience, not through tool abstinence.

"You may not even notice when it becomes too complex for a humble vi user." - If your tools don't get the job done, switch tools. If you find yourself saying "My tools would work fine if only OTHER PEOPLE would ...", you're using the wrong tools.

1) This error looks like it can't be recovered from. Just throw UnrecoverableError("Config file not found"), and you're done. The code is just as readable. Now if you also need to easily catch it, you need better pattern matching than Java and C++ can give you (Ocaml works well). Again, the code will readily display the relevant string. With C++ and Java, okay, drop the string. But try to limit the scope of your exception to the module it belongs to, and use context to give it a shorter name.

2) I agree

3) Thinking about it… you're probably right.

4) I agree

My point was, IDEs are double edged. Like debuggers. Without such fancy tools, you are forced to think before you write nonsense to the compiler. Good programmers will do the thinking anyway, but many others need some "encouragement". Optimizing for good programmers is a good heuristic, but sometimes, you also need to prevent the bad ones to make too many mistakes.

A similar argument can be made about functional languages: I can avoid side effects in C++ just fine, and I mostly do because its plain simpler most of the time. But many programmers need at least an Ocaml straight jacket.

OK, I thought you were taking exception(har har) to the name length, not to the fact that such an exception subclass was being used rather than simply filling in a description.

However, even then I think it's not quite so simple. In most cases simply putting in a text description for the exception would be sufficient, given language support when catching should it be needed. But if the application at a higher level needs to know what went wrong in order to inform the user in a friendly way, you'd need some kind of mapping between the exception and what to display on the screen. And if your app is internationalized, simply displaying the description of the exception would be even more problematic, especially if you have the same exception being thrown from different places (in which case you need to make sure none of their descriptions differ by even a single character lest you destroy the i18n mapping). I couldn't say definitely that subclassed exceptions would be superior in this case, but one could make an argument in favor.

Regarding 1)... Yes, in this particular case you could just throw an UnrecoverableError (or whatever) and pass a string with a message of what went wrong to its constructor. But that wasn't my point at all. I wasn't trying to make a point about how to structure code or deal with errors/exceptions, I was trying to make a point about naming conventions. My example could just as easily have been something like:

"PtgSL. PatagonianSeaLion. Which of these names describes the class better?"

The long name, of course.

Now whatever you do, long names should be reserved to infrequently used things. If a long name litters your program, you'd better use a shorter one. Conversely, short names belong to frequently used things. This is because a long name is a cognitive burden. On the other hand, one needs to learn what is behind each label, and don't want to forget it.

Fortunately, good long names (such as "PatagonianSeaLion") tend to be about very specific things. So specific that you rarely need them. But there can be bad long names, like "System_Out_Println". Something this pervasive should never have such a long name.