Earlier quoted context omitted.
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 exce…
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.…
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.