ContentProcessor. MessageReceiver. MessageSender. DataProcessor. There are so many it's hard to choose from. In my defense, I'm forced to use such names.
In the .Net world there's a naming convention of adding suffixes to classes - like FileNotFoundException which is kinda dumb IMHO.
I mean, you only use exceptions in two places: throw and catch. You know if you have throw new SomeClass() in your code, SomeClass is derived from Exception, same as if you have try {...} catch(SomeClass x) {...} - so why not just call it FileNotFound?
ContentProcessor. MessageReceiver. MessageSender. DataProcessor. There are so many it's hard to choose from. In my defense, I'm forced to use such names.
In the .Net world there's a naming convention of adding suffixes to classes - like FileNotFoundException which is kinda dumb IMHO.
I mean, you only use exceptions in two places: throw and catch. You know if you have
throw new SomeClass()in your code,SomeClassis derived fromException, same as if you havetry {...} catch(SomeClass x) {...}- so why not just call itFileNotFound?I'm not alone in this, there are other developers that share the same sentiment. In fact, I once read about a software engineer that got so sick of it he had all his classes add with Thingy.
Also, I once named one of my variables Yevgeni, but that was in honor of a fellow developer that got fired :-)
I suffer from this too (ManagementSecurityValidationException)