Simple Simon (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} pieman) wrote,@ 2007-10-18 21:11:00 |
|
Such a switch
All day today I was dealing with code that was prepared by people who were not as senior and certainly did not have the time to consider what it was they were programming. This leads to a difficult situation for someone to come into later.
Frustrating is really the better word for it. You never know where to turn to next to fix a bug and you just keep throwing extra debugging into it.
In contrast I am now looking at some code from a very large, long term project from Snap days. It is downright relaxing to be trying to navigate this code. I have not *ever* been into this section of code before, but I can follow all that is going on and why.
Once again I am impressed by J's ability to consider error conditions and to deal with them appropriately. And, further convinced that Java is a better language that PHP for anything of any weight or long lasting value.
Anyway, the code snippet that saved my butt from certain and irrevocable roasting last week was this:
Now, you wouldn't think that just randomly catching everything and dealing with it by returning 'null' would ever be truly appropriate. Shouldn't you try and figure out what is going on and *do* something about it. Not here. The returning of null if there was any issue means that the outside code fails gracefully and just does not display that thread. Like, say, when you have removed a bunch of user accounts in a cleanup and did not have appropriate code in place to make something more intelligent happen...something intelligent is already happening.
Where for most of the day things just failed. Sometimes in screen data dump, but usually more in a causing side effects as you go down sort of way. This was in playing with code that I have been working with off and on for the past two months.
All day today I was dealing with code that was prepared by people who were not as senior and certainly did not have the time to consider what it was they were programming. This leads to a difficult situation for someone to come into later.
Frustrating is really the better word for it. You never know where to turn to next to fix a bug and you just keep throwing extra debugging into it.
In contrast I am now looking at some code from a very large, long term project from Snap days. It is downright relaxing to be trying to navigate this code. I have not *ever* been into this section of code before, but I can follow all that is going on and why.
Once again I am impressed by J's ability to consider error conditions and to deal with them appropriately. And, further convinced that Java is a better language that PHP for anything of any weight or long lasting value.
Anyway, the code snippet that saved my butt from certain and irrevocable roasting last week was this:
try {
/* lots of code to get a message thread from the database */
} catch (Exception any) {
thread = null;
}
Now, you wouldn't think that just randomly catching everything and dealing with it by returning 'null' would ever be truly appropriate. Shouldn't you try and figure out what is going on and *do* something about it. Not here. The returning of null if there was any issue means that the outside code fails gracefully and just does not display that thread. Like, say, when you have removed a bunch of user accounts in a cleanup and did not have appropriate code in place to make something more intelligent happen...something intelligent is already happening.
Where for most of the day things just failed. Sometimes in screen data dump, but usually more in a causing side effects as you go down sort of way. This was in playing with code that I have been working with off and on for the past two months.
