|
Sander Rossel wrote: adding a try-catch does NOT solve the problem, so next time they tell you it's fixed, or whatever, tell them it's not and they should do their elephanting job.
Make it a policy so any exception handler needs to send the details of said exception to a log file. No IFs or BUTs about this one.
Then be ready to justify the presence of any exception in the log file. If the log isn't clean, someone needs to try harder to prevent the exception from happening in the first place.
It's a simple rule, but when enforced consistently, errors tend to be looked at more closely.
|
|
|
|
|
I disagree - sometimes exceptions are expected, and there is an appropriate course of action that doesn't involve writing to a log. I do think it is reasonable to insist that exceptions are dealt with, even if only writing to a log, rather than silently absorbed. Some groups I've worked in have that policy. For my own code, not so much, mainly because I don't have a log, never finding them that useful.
|
|
|
|
|
hpcoder2 wrote: I disagree - sometimes exceptions are expected, and there is an appropriate course of action that doesn't involve writing to a log
Those situations exist, but they have to be few and far in-between. An empty exception handler is frowned upon by my peers where I work, and while such instances do exist in our code base, they generally have to be commented and agreed upon. Typically it's because we use a (third-party) component that we know will fail under some known circumstances, is expected to fail, and there's nothing we can do about it. However, we do know how to handle the failure as gracefully as we can and carry on...and logging it would just clobber the log with stuff we know about and are anticipating. But these really are about the only acceptable situations.
Sometimes customers have situations you never would have anticipated in a million years, and you don't have access to their systems, so the handler is there to let you know that the unexpected happened. If the handler's silent about it, there's no way you'll never know, and a problem can be unnoticed literally for years, and this is when people chalk it up to a "glitch" (the use of that word is a serious pet peeve of mine).
|
|
|
|
|
I wasn't talking about empty exception handlers. I already noted that it may be reasonable to impose writing to a log if there's nothing else to be done.
|
|
|
|
|
pair programming for the fix - one writes the code, one writes the tests ?
really strict reviews
floggings
|
|
|
|
|
Garth J Lancaster wrote: floggings
Floggings needs to be the first action.
|
|
|
|
|
"It's always easier to do it the hard way." -- Blackhart
|
|
|
|
|
Back in 1975 D.W. Barron was saying: "... once a person becomes a programmer he should become a good programmer, part of becoming a good programmer is a continuing desire to become a better programmer...".
Point what is wrong and see if there is a desire to improve. If there is no desire, there is nothing anyone can do. It's just the sad case of a bright mind with a lack of spark.
Mircea
|
|
|
|
|
I never had much shame - if I see such attitude (and the age of the sinner irrelevant) I do speak - and aloud...
But seriously - speaking about such things is mostly helpful with intelligent, grwon-up people...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: speaking about such things is mostly helpful with intelligent, grwon-up people...
Exactly. And fortunately this person does listen.
As an aside, I find that speaking is overrated - most people don't have the skill to listen. And a corollary, the more a person talks, the less skill they have at listening.
|
|
|
|
|
I think applying quick kludge type fixes is okay with perhaps a ToDo tag with a note of some sort that is added to that code.
While software developers are in the business of writing beautiful elegant code, they are also in business and depend on providing the customer with a working solution so that their wages can be paid.
That beautiful elegant code is itself impermanent, so concentrating too much on the most elegant solution can be an exercise in imitating Ozymandias.
On the other extreme, apparently Oracle is something of a mess(English understatement) from a development point of view but they certainly bring in the money.
But adding try catch as a solution is not great unless that exception is logged somewhere within the catch.
Swallowing exceptions is generally a bad idea and perhaps that's what needs to be explained to them.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
There is no short-cut to knowledge. The best way for this person to learn is for someone more experienced to pass their experience down and explain why their solution was not the best one. If they really are smart they will understand. No-one writes perfect code from the off, the only ways we learn is a) by our mistakes (expensive) b) having someone who knows better teach us (cheap). This issue has let you swap "a" for "b"
|
|
|
|
|
Without more detail, it's hard to give specific advice. I'm presuming from your question that you've done a code review or studied this problem, so you have a valid reason for wanting to go further.
Seems as if a review is in order. Ask them to defend their implementation, and come prepared with your ideas to provide guidance and education on why a more thorough change is necessary. Try to guide them into thinking deeper..."what about situation X?"...so they understand the way you see the problem and can apply that to other problems, not just "I'll just go implement Marc's suggestions."
Who knows, maybe after a discussion, it might even be you that comes around. Maybe it's not necessary to refactor as much as you see.
Also remember that's it's o.k. to do a temporary fix with the intention of going deeper later for reasons of budget/time/etc. Document the full-featured change in change control, make it a story with some priority, and make sure that documentation includes the quick fix to keep things running along.
|
|
|
|
|
Create a check in trigger that rejects any delta that contains both "try" and "catch".
Or is that just another "first solution" answer.
|
|
|
|
|
englebart wrote: Create a check in trigger that rejects any delta that contains both "try" and "catch".
That is an excellent idea!
|
|
|
|
|
I work with a guy like that. The solution to any problem always lies along the straightest possible line between the problem and the desired solution state. He's very good at this sort of thing, and it works in the short term, but we've learned to follow up on anything he does to make sure his corrections make senses in the broader scheme of things.
I'm not being critical of the guy either - he has an amazing talent for going from a vague problem description to the region of code where the core of the problem lies, even when he didn't write the code himself.
Software Zen: delete this;
|
|
|
|
|
This sounds a lot like "how do you teach someone to think?". I'm not sure if you can, but in the past I've given instructions like "Come back and tell me five different ways of solving this". They find the first answer but then have to chew the pencil a while.
|
|
|
|
|
I plan to pursue a certificate in Microsoft Azure fundamentals, and then one in Azure development.
However, all of the jobs require actual years of professional experience in these technologies. My current experience is in desktop LOB development.
Does anyone have any recommendations for the approach I should use when applying for such jobs?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Always tell the truth, you may be able to convince prospective employers that all you other experience counts.
|
|
|
|
|
Thank you, that's good advice. I plan to be honest.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I'll back that up by saying I'd employ a smart, pragmatic problem solver who is open and honest and shows they can learn over someone who 5 years of experience but who won't expand their skills or is an arrogant SOB any day of the week.
Knowing a tech is super handy and a headstart for sure, but an employee is always going to have to learn a bunch of other stuff anyway so a solid, well-documented franework or service is the least of the worries.
Oh, and Fake it till you Make it seems to work too.
cheers
Chris Maunder
|
|
|
|
|
Thanks Chris, I appreciate you weighing in. I'm thinking about what arguments I can make along those lines now.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I hope you're refering to the impostor syndrome.
Wrong is evil and must be defeated. - Jeff Ello
Never stop dreaming - Freddie Kruger
|
|
|
|
|
That's actually a tough one. It's not like desktop development is directly transferable to Azure development, even if you are "one smart cookie." The company will incur a cost for your learning curve.
So I guess I'd say that - something along the lines of "I'm in the process of getting a certificate...and I realize that there will be additional learning that only actual experience can provide and I'm confident that I can minimize the cost of that to you."
Ideally, the fact that you're conscious of the issue should count for something!
|
|
|
|
|
Thank you for your perspective. I hadn't considered that.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|