- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Min is the reason why you should keep files on people that applied, as you are allowed to, for 6 months, with NOTES on what they admitted lying about.
VB isn't that hard I suppose, what's the worst that could happen.
VB life support machines. Shudder.
Admin
You haven't heard of them? The Kevorkian Institute uses them almost exclusively.
Admin
Well, with VB6 at least you can't put life saving critical code in a finally block.
Admin
Is that a) life support machines developed in VB, or b) Min, the "machine" used to keep a VB application alive?
Admin
Not to be picky, but as someone who was promoted from tech support to programmer I've got a question. Did you actually ask any technical questions or are you just blindly assuming (like the wtf in your first example) that she didn't know how to program since she lied to get into the interview?
Admin
A similar thing happened here. We had a doctor of mathematics and computer science applying here telling us all about his skills in ... well, almost everything. In short, he presented himself as a programming god humbling all of us little grunts.
In reality, he had no qualifications. He wrote his thesis on formal languages, which is probably the most theoretical part of computer sciences. He had no experience in programming or in designing business applications. He failed in writing a one-line-.NET-program (create an account in a CRM-system with just a title) after ONE week. He couldn't even read an SDK. However, HE was VERY surprised when he found out that we "simple grunts" could read UML without being a doctor of computer science.
When we found out that he worked as a medium and clairvoyant on some 0900-number-company (stumbled over it when we googled his name), his days were counted...maybe this guy and his story would qualify for an entry here...
Anyway, this scheme seems to work more often than you think.
Admin
Does it matter? From my perspective, lying to a potential employer is a show-stopper, hands down.
Admin
Surely TRWTF is giving someone who has 'Oracle T-SQL' and 'Microsoft Solaris' on their CV the benefit of the doubt.
That would have been setting alarm bells ringing immediately for me.
Admin
Blind assumption is safe in this case I believe.. Perhaps they were looking for someone with experience programming?
That's what I tend to do...
CAPTCHA: ingenium (!)
Admin
Well, yes, since she was already an employee in the company apparently.
Admin
From my perspective, getting caught lying to a potential employer is a show-stopper, hands down.
Admin
Read the article again. It seems to be saying she received the position in the other group after being denied by Alex's group.
Admin
Yeah, lying finally got her a job.
Admin
never put critical business transaction code in finally blocks.
I put all my absolutely critical business transaction code on a piece of paper, photograph it on a wooden table, then post that picture next to my computer. that way when the power goes out, I can execute the code myself.
where are you supposed to put the code? Magic fairy blocks?
Admin
package test;
public class minBean {
private String min = "Brillant";
public String getMin() { return min; } }
Admin
Admin
I tend to use "finally" as an attempt to gracefully fail after all other avenues have proven fruitless; I always sort of thought that was the point of finally...To clean up after failed Catches. I tend not to use finally though, so I'm not the best person to opine.
I guess, thinking about it, you could use it as a sort of general cleanup...Seems...I don't know...Odd.
Admin
That's what I was wondering. If you want a guarantee that your code will be executed... well I guess there are no guarantees. Don't use computers to execute business critical code?
I guess my point is, if the computer is suddenly shut off, it doesn't matter where your put your code*, finally or no. It's not going to be run if the machine is off.
*Note: I know it matters where you put business critical in an app but my point is, Alex was being a tiny bit pedantic in my opinion.
Admin
"Which version of Solaris do I need to run Linux?"
The only blooper I might pass, however, might be something like "Microsoft Sybase" or "Sybase SQL Server", as they are practically the same thing. Except Sybase actually runs in non-MS platforms!
Admin
Well, like others said, catching her lying in the interview pretty much precludes anything else.
But I'd guess coupling that with glaring errors like 'Microsoft Solaris' on her resume might be a worthy indicator of her programming ability
Admin
Shortly before I worked a my current company, we hired a network engineer named Bob. He had a bunch of certifications and came recommended, from where I'm not sure. During the interview, my boss described the work environment (NT4) and expectations. The boss wasn't going to insult his intelligence by asking silly technical questions.
Bob is the reason now we ask a lot of technical questions and never rely on anything the candidate thinks about their own level of knowledge.
Bob's first day or so, he was asked to install Windows NT on a server and configure IIS.
Bob (aside to new co-worker) "Does he actually expect me to do that?"
Bob was offered a new position as a jr level guy, at a much reduced pay rate. Luckily, he turned us down.
Admin
I still don't think that's safe to assume. It could be that she's never used those skills and technologies in a professional capacity. Especially if there was a language barrier or anything. A WTF response to a valid programming question would have made this a great addition to the WTF files. Give me a smart person who understands logic, and I can teach them how to program. Give me a dumbass who has a CS degree, and they'll appear on this site eventually.
Admin
The secret is not to guarantee that your code will be completely executed, it is to guarantee that it will not be partially executed. Having a program fail completely is no problem at all...No harm, no foul, just run it again. Having it partially fail will screw up your whole week; that's why he mentioned database transactions.
Using a Finally like they used it would be fine if all the Finally did was commit the transaction or something...Trusting it to break new ground is a recipe for the sort of subtle failure that makes you tear your hair out.
Admin
package test;
public class Min { private String min = "Brillant";
public String getResume() { return "I know VB"; }
public String getJob() { try { lieAboutVB(""); } catch (GotCaughtException e) { getJobSomewhereElse(); } finally { } return "finally, yay it worked!"; } }
Admin
I'm sure she had some basic programming knowledge, but we really needed someone who had experience with the "keywords" she listed. It was a big, boring company, so 30% of the job was navigating the bastardisation of the specific technology stack, 69.5% was communication/bureaucracy, .5% was actual programming.
Admin
if(computer.IsOver || computer.IsAboutToBeOver) { //execute critical business code }
I win.
Admin
I almost never use finally, if you want to do stuff after a try-catch block then you don't really need the finally, these two blocks are almost always the same:
try { result = a/b } catch (exception) { //handle divide by 0 } finally { return result }
try { result = a/b } catch (exception) { //handle divide by 0 } return result
also, any "mission critical" tasks would fare the same, and should have been recorded in a log system like a database uses instead of being 100% reliant on the code always executing
Admin
Note: finally blocks will run even if the exception thrown is an unchecked one (i.e. RuntimeException).
Admin
Fair enough. I basically got the job because I was eminently trainable, and the job had the same breakdown :)
Admin
We have a couple places in our Java legacy code that use the following paradigm (simplified for readability, of course):
public static int tester(String s) throws Exception { int retval = 0; try { retval = Integer.parseInt(s); } catch(Exception ex) { throw ex; } finally { return retval; } }The exception gets eaten and the method happily returns something, pretending there's no problem at all. Fixing it is on our list of things to do. Nothing's gone haywire ... yet.
Admin
actually, you could return to jump over the finally, code still executes, just not the finally.
Admin
finally is intended for (an attempt at) graceful cleanup when you plan to propagate the exception up the stack. At least that's always been my impression.
Admin
I believe the difference is, the finally block is in scope to access variables declared within the try block, while code added after, but not in a finally block, is out of scope.
Of course that depends entirely on the language and it's scoping semantics so in some cases, there may be no difference. And also I suppose where the variables are declared.
Admin
I'll agree with you there. but I don't like exceptions to go outside of the function it happened in, I tend to prefer using if statements to validate input and take care of any problems that arise. if I have to interface with something that throws exceptions (for example most pre-built DB handlers only use that) I use try-catch as a replacement for if. if this code doesn't work, handle all the errors and cleanup gracefully and return a standard response of what happened instead of complaining to the routine that requested the function to run.
Admin
Any idea where Min is today? She sounds ... familiar.
Admin
Wow, alot of people don't understand try/catch/finally here. It makes no sense to put a return statement in your finally block. If you think it does then you miss the point of finally.
Admin
I don't think this person and Min are the same at all. This guy is far worse.
He had a doctor of mathematics and computer science. She did not claim any advanced degree. Min's interviewer was likely more careful about skills. The other interviewer probably just assumed he knew how to program.
Min admitted she knew no programming after she was caught. The good doctor told a lecture full of lies.
Padding an entry-level resume is not as bad as using a Ph.D. to break into a field!
Admin
I'd even suggest Min is the reason you stop looking at requirements (unless they are absolutely required) and start looking at abilities. Too many employers would take a fresh graduate that lists 15 languages you want them to know on their resume they "learned" in some school at god-knows-where over someone who has been in IT for a decade, but only has 10 of the 15 qualifications you want. And I'm just talking about offering them an interview. Once you offer the interview, it becomes obvious who is best for the job.
Guess who is going to figure out how to get the job done faster and with fewer errors... And guess who is going to be far more useful to your company when hard times come.
Admin
stack overflows will STILL call the finally
package test; public class miscTest { public int loop(int x){ return (loop(x+1)); } public static void main(String[] args) { try{ int x=0;int y=5; miscTest test = new miscTest(); test.loop(1); double t = y/x;
}
finally java.lang.StackOverflowError at test.miscTest.loop(miscTest.java:8) at test.miscTest.loop(miscTest.java:8) at test.miscTest.loop(miscTest.java:8)
Admin
Those aren't even typos. They're blatant errors which are mix-mash of various technical terms. I could understand misspelling "DCOM" as "DCMO". And yes, your HR department needs to be told that not only did she lie on her resume, but she said she lied to the interviewer.
Admin
I had one like "Min".
I scratched the person, call him "Max" just for the sake of inventing a name, off the list after a brief phone interview on some fundamental technical grounds as well as a sneaking feeling that there was something wrong.
A few months later, I was asked to take a look at some resumes for another position and there, again, was "Max". I mentioned my misgivings to the manager involved and dismissed the whole incident from my thoughts.
A week or so later, there was "Max", settling into a workstation, having been hired over my misgivings. I told myself, "okay, I'll give 'Max' the benefit of the doubt and besides, 'Max' won't be working on my project, so it's someone else's problem."
Except that about a month or so after that, for reasons which remain opaque to me, "Max" was assigned to my project as a Java programmer. "Max" claimed to be a database person and whined about having to program in Java, got into conflicts with one of the other programmers, and never actually completed anything useful -- I don't think I even got a Paula "brillant" from "Max".
"Max" then wondered why his performance reviews were mediocre and complained of that his talents weren't being recognized.
"Max" eventually got reassigned to another group which, to the best of my knowledge, has never produced anything beyond interiminable meetings and hangs on by attaching itself remora-like to other successful projects. Everyone seems happy.
Admin
This answers it pretty well...
... but to expand on that, from a code perspective, if you're lucky enough to have an underlying transactional system, it's like this:
try { StartTransaction(); DoStuff(); } catch { RollbackTransaction(); } finally { CommitIfNotRolledBack(); }
The underlying transaction system will auto-rollback if it never gets committed or rolledback. However, the real problem occurrs when someone doesn't have an underlying transactional system.
try { ProcessAllRecords(); } catch //(or a conditional finally) { UndoAllProcessing();
}
If ProcessRecords() is not designed to be re-entrant, then you're pretty much screwed if an error occurs and UndoAllProcessing() never is run.
To make matters worse, these problems compound themselves, so the second time you run the program, the un-catchable exception occurs again and further corrupts the underlying data.
Finally should be used for things like memory cleanup so you don't end up with leaks, etc. If the program never hits that kind of finally block, it's OK, since the whole thing has crashed and burned already, and memory leaks are the least of your worries.
Admin
put life saving critical code in a finally block...
Life saving? No. Clean up? Yes:
class Doctor { public Doctor() { goToMedicalSchool(); doInternship(); } public void treatPatient(Patient patient) { try { diagnose(patient); treat(patient); patient.setStatus(Better); } catch (TreatmentFailed tf) ( callPriest(patient); patient.setStatus(Deceased); // cheap joke re: patent.setStatus(FileNotFound); } finally { discharge(patient); // to family or mortician } } }Admin
The point was that the assertion that code in a finally block is always executed is wrong. Period.
For instance, in C#, here's an example of a finally block that'll never execute, even without pulling the plug from your computer. The only output will be "Before fail fast":
using System; using System.Collections.Generic; using System.Text; namespace FailFast { class Program { static void Main(string[] args) { try { Console.WriteLine("Before fail fast"); Environment.FailFast(null); Console.WriteLine("After fail fast"); } finally { Console.WriteLine("in finally block"); } } } }Admin
Reminds me of interviewing candidates with Active Directory experience. They would put 'AD' on their resume so we would ask them about it. They would typically say any of the following:
"AD stands for Active Directory." "AD is what is used when you log in." "My consulting company told me to put that on there."
When never found one that had actually had REAL experience with AD, so we hired a recent college grad and trained him. He was cheap and we could mold him into the developer we needed.
Admin
Someone please educate me a bit: How does a database survive a power cycle in the middle of writing a transaction?
Captcha: appellatio (A program that sucks?)
Admin
Admin
The arguments over try...catch...finally remind me of a story about the Java finalize() method. This mehod has far worse indeterminant behavoir than try...catch...finally.
We had an otherwise brilliant programmer, with a C/Perl/CGI background but not Java. He even had a Master's degree in computer science.
He was tasked with writing a JSP webapp for the company. The application usually ran fine, but occasionally it randomly executed some code.
After much discovery, he found out that his AppClass.finalize() also overrode the Object.finalize() method. The garbage collector was running his method at random intervals.
Admin
The arguments over try...catch...finally remind me of a story about the Java finalize() method. This mehod has far worse indeterminant behavoir than try...catch...finally.
We had an otherwise brilliant programmer, with a C/Perl/CGI background but not Java. He even had a Master's degree in computer science.
He was tasked with writing a JSP webapp for the company. The application usually ran fine, but occasionally it randomly executed some code.
After much discovery, he found out that his AppClass.finalize() also overrode the Object.finalize() method. The garbage collector was running his method at random intervals.
Admin
I dunno could have just been a missed comma.