|
This look like obfuscators's poop... Obfuscator creates this kind of code all over the place ...
|
|
|
|
|
private void Frobinate()
{
string result = CreateRecord();
if (result == "")
{
}
else
{
if (MessageBox.Show("Record already exists. Do you want to update it?", MessageBoxButtons.YesNo) == DialogResults.Yes)
{
UpdateExistingRecord();
}
}
}
private string CreateRecord()
{
try
{
return "";
}
catch (Exception e)
{
return e.Message;
}
}
This pattern is absolutely brillant because nothing else could ever cause a problem. Authentication can never be incorrect. The server can never be down. Bob can never be taking a break to oil the hamster wheels.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Give the guy a break. At least he did try.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
You caught that then?
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Well sure. I couldn't just throw it away.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
You could have made an exception in this case!
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Never knew it was a pattern and had a name!
I can start using it now...
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
If you're looking for other interesting desings, might I suggest the thousand plus line OnClick() method with at least ten levels of indentation pattern. Remember methodcalls have a performance overhead, so inline everything no matter how many copies you end up with.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
An appropriate design pattern should be applied indeed. 10 levels of indentation is not good, even if they were hidden in methods. A loop over a list of conditions or strategies maybe.
Besides, if we have a framework object Exception, then why return a part of it (Message) instead of a reference to the object itself (or null if no error)? Makes no sense to me. We should either return an error code or make it OO, depending on what is better in a given context. Mixing those two approaches is a bit... unusual. I am no expert, please correct if I'm wrong.
Greetings - Jacek
|
|
|
|
|
Sadly, I know programmers who love to use that pattern. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
It wasn't a hypothetical for me either. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course):
MessageBox.Show("Should never get this message.");
-NP
Never underestimate the creativity of the end-user.
|
|
|
|
|
That's awesome. It's what happens when you feel you need a try but have no clue what to do in the event it ever does fail.
Also, it could be that if the developers ever saw it then they knew some approach was not working and could fix it but assumed their approach was right and therefore should never see it.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
I have gotten some of those before. Had a look at the code and can't see how it could possibly get there. Normally it is an indication that something has gone awry. Possibly stack corruption or something like that. The thing is they don't normally print the if or case bits so you haven't a clue how it got there.
|
|
|
|
|
I can beat that - some code I was asked to help with had hundreds of methods where a database query was wrapped with:
try
{
}
catch (Exception exception)
{
exception.Message.ToString();
throw new Exception("Exception occured");
}
Needless to say, every call to one of these methods was wrapped with:
try
{
CallTheQueryMethod();
}
catch (Exception exception)
{
MessageBox.Show(this, exception.Message);
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yeah, that's nice too. I've also come across several completely empty catch statements. Those are fun to debug: "Error? What error?"
-NP
Never underestimate the creativity of the end-user.
|
|
|
|
|
This is probably because the programmer didn't know how to handle the error or what to do with it.
|
|
|
|
|
All programming is about handling errors. A whole life is about handling errors, actually. I bet the programmer was a no-lifer. 
Greetings - Jacek
|
|
|
|
|
|
Here on Code Project somebody made an excellent point about empty catches: This piece of code
try {
SaveUserData();
}
catch
{
}
is equivalent to:
try {
}
catch
{
}
Greetings - Jacek
|
|
|
|
|
Wow, this post's timing is perfect. I've been tracking down a bug this morning where data is not being saved to a database table when it should be (in the same code that started this thread). It came down to an error being thrown by the database, but caught in an empty catch statement. As frustrating as that is, it has been going on for a couple of years...nobody seemed to care until now, so why bother?
-NP
Never underestimate the creativity of the end-user.
|
|
|
|
|
But at least it compiles, doesn't it???
I think some people use exceptions only when they have to. For example in java your code wouldn't compile without catching it or declaring the exception in the signature of the function that encloses your code. Result: people catch it and either ignore it or "return false;" or "return null;". Problem solved.
|
|
|
|
|
Hmmmm
I was once interviewed by a person who had asked me "Why are Exceptions Bad?"....
Without catching the drift of his tone, I replied "I don't think Exception are bad" ....
Interview ended few seconds after that
I guess I was lucky that I did not get the Job!!!
|
|
|
|
|
Well, it depends on the language and the scenario. I personally love exception handling but in some cases I avoid using exceptions. For example in C++ I don't like it because the rules are too loose (you can throw by value, reference, pointer, there is no standard exception base class/exception chaining): the result is that most libraries simply don't use it or use it only internally. If you have to wire together several libraries with their own exception types that can also be a pain in the ass. Another scenario where the presence of exception handling sometimes matters is extremely performance critical, maybe low level code.
One of my friend told me a tale about one of his job interviews. The interviewer ask him the following question: "What is the purpose of smart pointers?". Of course my friend told a tale about object ownership and resource allocation/deallocation. Finally the interviewer gave him the right answer: "Smart pointers are useful because of the exceptions!". It clearly shows the incompetence of the iterviewer, he simply didn't understand that smart pointers are just a possible application of RAII, and he has no clue about object ownership, RAII,...
|
|
|
|
|
This just shows the incompetence of the programmer who wrote it: he didn't understand a core feature of the used language: exception handling/propagation. The result is extremely hard time or mission impossible when it comes to finding bugs especially from user error reports (without stacktrace of course). If you get a job and you see code like this I recommend doing the following:
- ask someone whether a total refactorization is possible (maybe not because of time, safe-player boss, ...)
- if refactor is not possible then search for your next job
Working on such a codebase is a waste of time from your valuable life.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
