There are many times in some shops I’ve worked where I’ve seen developers return a boolean back form a method for a transaction fail vs. succeed as a way to determine whether to do something next in code. A transaction could be any type of work. I talk about transaction here in a generic way; insert into a db, copying of a file to a directory, you name it.
Here’s an example:
public bool DoSomething(int someID, ..., ...)
{
return db.DoSomething(someID, ..., ...);
}
In this example the caller would get a true/false returned based on if the code was successful or not.
Why is this horribly a bad way to handle success/failure of something that “happened”? Well here are 2 obvious reasons:
1) The caller gets a false back. Ok, what the hell does that mean? What if I need to know why for obvious debugging/troubleshooting purposes, especially if I’m gonna call this method from a service
2) I’m not returning something back that is useful. A descriptive error is useful. If not that then I should be sending back a more useful object that I can do something with. No, a boolean in this case is not a smart idea. It tells me something happened but nothing more. It keeps me blind especially if I ever have to debug further at any time to figure out why it was false!
To me, that’s a very lazy coding unless you want to purposely eat the error. In this circumstance there’s no reason to eat it basically by sending back a false. If you’re logging it fine but again, to the caller it’s not helping them at all. While it might work, it’s not going to help when you keep getting false back and wished that the method would be much more helpful and not so mysterious.
And you really shouldn’t be eating the error unless you have a good reason for it. In this case you’re not handling anything and you’re not doing your caller any good or the rest of the code to be built on top of this because then that code becomes lazy also because all it has to do is check for false. Soon all your code is checking for true/false and you have no real debugging capabilities when you wonder why am I getting false, false, false when you step through your code on a bunch of method calls to try to figure out wtf is going on.
This is nothing new, just a reminder again to write write clean maintainable code.
Technorati Tags:
SubversionAfter restoring a backup repository today and then checking in some code to it, I noticed that the commit showed successful but when browsing the log I did not see it in there. In fact no commits were showing.
It ended up being the History cache. The solution was to disable it and update the existing cache (who knows if there’s a quicker/easier way but this is just what I did in the spur of the moment).
So uncheck the caching (I don’t really care about performance):
Then I updated the existing cache (again I don’t know if this is necessary, I just happened to try it without looking much into it):
Technorati Tags:
SubversionToday I had to restore a backed up repository. I backup our entire C:\Repository on our dev server and simply copy it back to restore it as the server had crashed (don’t ask me why..I was not involved nor was there an image to just take and restore).
Anyway, after I did, the repository version was perfect and up-to-date so we could carry on. One error I did get initially after starting to use the restored repository was this when I tried to check in a test change:
This simply happened because my C:\Repositories folder was set to read-only on our Server 2008 dev server. So, I simply removed that flag on the folder and it was fine and I was able to check in my code again.
