The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Your rant made me laugh because you described the entire process of dealing with user authentication just as I experience it each time I have to deal with it.
Dealing with it is basically like a stroke, topped off with an brain aneurysm ,salted with plenty of cursing.
This way, if I'm debugging, I can always examine it, even if I ignore it in the code. I'm often called out for doing this in some of my articles here.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
Which brings us to another philosophical question: What to do with an exception that does not hurt, can't be prevented, nor meaningfully handled?
Sweep it under the rug, like it is done here? Maybe there is not much you can do about it once it has happened. Maybe it's not harmful, but then you would be using exceptions as a means to control program flow. That's not a good idea.
I would say that it's better to use such Pokemon exception handlers to catch and log all unexpected exceptions and log them away. Once in a while someone should read these logs and take a look if this exception can be prevented or handled. Sweeping this under the rug is just lazy.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
What to do with an exception that does not hurt, can't be prevented, nor meaningfully handled?
In most cases, the "expected exception" will be a more derived type than System.Exception. The catch block should catch that derived type, and have a suitable comment to explain why it's ignoring the exception.
Of course, there are always exceptions. Back in the early days of .NET, certain invalid input passed to the ColorTranslator.FromHtml[^] method would deliberately catch a FormatException and wrap it in a System.Exception, which made it painful to catch. (Especially as this pre-dated C#'s access to exception filters, and before C# stopped handling corrupted state exceptions[^] by default.)
I reported the bug on the Connect site (which was "retired" last year[^], deleting all of the information collected there). I was told that it couldn't possibly be fixed, because that could be a breaking change. They couldn't even change it to wrap the FormatException in another FormatException, in case somebody had written code which relied on the exact exception type.
Thankfully, they seem to have come to their senses and fixed it sometime around .NET 2.0.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
JSOP's code shown above sweep it under the rug. I can't see why this should the right approach. It would be better to add a "throw;" after his "warning elimination code fragment" or then log the excepiton.
It does not solve my Problem, but it answers my question