Tough interview question
-
As I said in this interview, frustration is part of the job of development, compared to other jobs where the same actions give the same results fairly reliably. It's not whether you get frustrated or not, but how you react when you inevitably do get frustrated.
-
Brady Kelly wrote:
So this guy asks me what what my general exception handling policy is.
My standard answer is: I don't write code that throws exceptions. I guess you guys do, so how do YOU handle your buggy code? Marc
Good answer, if I wasn't in the formal context of a job interview I would have used it. If something results in an exception on prodcution, there is really nothing you can do except to spare the user the Yellow Screen of Death. If you need to handle 'special' exceptions, then your code needs work. If your infrastructure guys set you up the bomb, then the end user still can't use your app.
-
Good answer, if I wasn't in the formal context of a job interview I would have used it. If something results in an exception on prodcution, there is really nothing you can do except to spare the user the Yellow Screen of Death. If you need to handle 'special' exceptions, then your code needs work. If your infrastructure guys set you up the bomb, then the end user still can't use your app.
Brady Kelly wrote:
If something results in an exception on prodcution, there is really nothing you can do except to spare the user the Yellow Screen of Death.
Even that isn't enough for some people. Had a user last week get an error. The way I handle exceptions is to show a Whoops screen to the user letting them know that the problem has been reported to the appropriate person (me). And I get the email containing the YSOD plus a bunch of other error info. Whatever. This user then proceeds to try again...20 times. Same thing over and over and over, like he expects it to magically start working if he keeps entering the same data and hitting the submit button.
-
Eric Xue (brokensnow) wrote:
that's kind of question we pretty much asking ourselves on the daily-basis
Me too, but it's kind of a given in software development, something I do almost intuitively. When I'm asked to verbalise it, unless I can sit down and give it some concious thought, I find the request a little difficult. The rest of the interview was quite pleasant though, more discussion than interrogation. I think I would really enjoy working with the guy, even if he does consider model validation, data annotations, and ORM's to be slow and messy, new-fangled crap, despite being a few years younger than me.
Slow and messy during runtime or dev time? Because computers are way faster than programmers, and programmer time is a lot more expensive...
-
Brady Kelly wrote:
If something results in an exception on prodcution, there is really nothing you can do except to spare the user the Yellow Screen of Death.
Even that isn't enough for some people. Had a user last week get an error. The way I handle exceptions is to show a Whoops screen to the user letting them know that the problem has been reported to the appropriate person (me). And I get the email containing the YSOD plus a bunch of other error info. Whatever. This user then proceeds to try again...20 times. Same thing over and over and over, like he expects it to magically start working if he keeps entering the same data and hitting the submit button.
GenJerDan wrote:
This user then proceeds to try again...20 times. Same thing over and over and over, like he expects it to magically start working if he keeps entering the same data and hitting the submit button.
He's punishing you (the error report recipiant) for writing code that crashed :) Actually, he's just mad and frustrated. Too bad there's nothing you can do for him that won't make the next time even worse.
patbob
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
Don't you love rhetorical questions from managers who have nothing better to do than to dream up questions like that ?
-
GenJerDan wrote:
This user then proceeds to try again...20 times. Same thing over and over and over, like he expects it to magically start working if he keeps entering the same data and hitting the submit button.
He's punishing you (the error report recipiant) for writing code that crashed :) Actually, he's just mad and frustrated. Too bad there's nothing you can do for him that won't make the next time even worse.
patbob
It's nice to see that the dev community hasn't lost sight of the need to serve the customer ;P
-
Slow and messy during runtime or dev time? Because computers are way faster than programmers, and programmer time is a lot more expensive...
Funny how end-user time is never considered in that equation :) ?
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
I try to follow the rule "Never catch an exception you can't handle" although I do have catch blocks that add context and rethrow. When an unhandleable exception reaches the user, apologise, generate a report (crash dump, log file etc), and exit cleanly. What else could you do?
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
This is more like a question for a politician who just needs to keep the conversation going aimlessly. There is no solution for system crash. Otherwise, we'll not have the term "blue screen of death". One exception is that if crash happens very often whenever your software is running, it is an indication that your software has an issue.
TOMZ_KV
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
It depends on the systems requirements of couse. If the system is required to reset itself automatically if a fatal exception is caused logging an error message then that is how I will build it to be. Maybe the system requires a transfer to second 'parallel' system in the case of a fatal failure. A thing that I will look at is the fatality of the various exceptions that can be caused and structure is accordingly. At the end of the day any exception handling depends on the system requirements (what does the customer want).
-
Brady Kelly wrote:
even if he does consider model validation, data annotations, and ORM's to be slow and messy, new-fangled crap
Well, they are...
Brady Kelly wrote:
despite being a few years younger than me.
He is wise beyond his years...
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001ORM's provide functinality using code that you (or your dev team) didn't have to write nor (directly) maintain. For that, they have thier benefit IMHO. ORM's are not the answer for all situations, but to call a technology/framwork 'crap' shows that he is not objective.
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
It also depends what exception was thrown and why. Is it something that means the end of the world, or just some recoverable program error? System calls can throw exceptions that aren't fatal, just an indication of a problem you can maybe deal with. I have lots of try / catch blocks in my code. And languages like Ada expect exceptions from the language defined runtimes...
-
So this guy asks me what what my general exception handling policy is. Log the exception and allow it to propagate. OK, what would I do to avoid the system crashing and the end user sitting staring helpless at an error message, unable to do business? What could I answer? Redundancy, parallel systems? No, the system you are currently running crashes. Oh, user friendly error message, error must be logged and developers notified. I mean, really, on a system coded and tested properly, you can't really do much more. Some people are never happy.
The question may have been designed to see if you had any actual experience with exception handling. From you answer, I can guess that you didn't. There are basically three things you can do with an exception. Abort, Retry, or Fail (ARF). Abort is logging an error message and quitting. It's easiest, but least helpful because it denies the user the use of his program. You wouldn't want to implement this policy in a nuclear reactor or jet cockpit computer, because if the program stops, the reactor or jet is still doing whatever unusual thing it was doing that executed that untested branch of code. Retry is a strategy. It depends on the exact exception, but sometimes you can release resources and retry, or cancel background operations and retry, or do some kind of thing that makes the program feel happier and retry. Fail is also a strategy. You simply discard the command or bit of imput that caused the exception, unwind the stack to the main loop, and read the next event, instruction, or whatever. Is it horrible that you dropped some command or event or operation on the floor? Yes. Is going on with the next thing better than stopping? Most of the time yes. And you can give the user a chance to quit if now is not a good time to go on. Fail is what you do when you divide by 0 or dereference nil. You can re-do that current operation a hundred times, and it's always going to dereference nil. Yeah, it's scary to go forward after you dereference nil. Maybe the memory will be corrupted and the program will totally crash. But that is no worse than if you log a message and quit. Either way the program is stopped. And if you're lucky, you didn't have to fail an important or irreplaceable event, and the program goes on pretty well. There is one other strategy; do the same job using different code or hardware. Such a strategy works ok if you're NASA and have resources to code the program twice using different languages or whatever they do. It's too expensive for most of us.