Bugs, developers and testers

re: Bugs, developers and testers

rakeshrajan — Wed, 03 Aug 2005 15:08:00 GMT

Hi BTX,

That's interesting - and again, it's yet another exception handling mechanism. I will be writing on the different styles I have gathered shortly. Thanks a lot for sharing!

Warm regards,
Rakesh Rajan

re: Bugs, developers and testers

rakeshrajan — Sat, 30 Jul 2005 11:00:00 GMT

"what generally is your approach to handling exceptions? Different people have different approaches to handling exceptions and I was just curious. "
my approach is quite simple, but very effective:

everytime I start a new method, the first thing in there is:

try try
except
on E:Exception do
raise Exception.Create('Error in method X:'+E.Message)
end finally
//release any resources
end

of course, this is a very generic example, and the code is written in Delphi, but that's the idea, in addition to that of course you want to check for specific exceptions depending on what your code is doing instead of just E:Exception
the other thing to do is when there is code that can potentially create an exception, I always surround that in a try..except

try try
try
//process something that may raise an exception
except
on E:Exception do
raise Exception.Create('Error processing X:'+E.Message)
end;
// some more code here...
except
on E:Exception do
raise Exception.Create('Error in method X:'+E.Message)
end finally
//release any resources
end

again, the code is generic. Many people might think that this is way too much exception handling code, but it actually saves you TONS of time, both debugging and finding any errors or bugs because you are actually writing the cases for when the code fails

and so, with this code, if there's something unexpected, I get something like:
Error in method X:Error processing X: (error description here)

that's very complete information to tell you where to actually go and fix the problem, of course there are always third party tools to give you all this information, but this is simple and works almost just as good

the last things to do with the exceptions are,
- trap the exception at the highest level, before it hits the user
- always log the exceptions
- and what to do with the exception depends on the type of application

re: Bugs, developers and testers

rakeshrajan — Sat, 30 Jul 2005 02:04:00 GMT

Hi Andrei,

Hmm...that is a very different genre.

IMHO developers are the people who should write unit test code, because it's just another sort of coding! Moreover, code in nunit is tightly coupled with the actual code, which could undergo frequent updates in the future as it matures.
In short, testers won't fit the bill. Sadly, this means that in addition to hoping our developers will write good code, we would also have to trust our developers to write good testing code too!

Unfortunately, this is slightly risky for many reasons:
1. More code to write for developers = more effort = more time
2. As soon as actual code changes, test code will also have to be changed
3. Same old reason - can't trust all developers to test well
4. Bugs in actual code is natural...but bugs in testing code - that's too much! (Who will test the code that is supposed to test code?)

Once again, having a tech lead to shoulder the responsiblity of writing nunit code might solve this problem to an extent.

Hmm...it's tough to create good software

- Rakesh Rajan

re: Bugs, developers and testers

rakeshrajan — Sat, 30 Jul 2005 01:08:00 GMT

Hi BTX,

> "These are things routine...
Hmm…it is sad that even if the intention of tools is it to make programming easier and increase productivity, negative effects also exists. Too many people just use tools blindly without finding out what it does. In fact, ASP.NET postback itself is a great example – I have seen many people who fail to realize that the postback is simply a form action (available for a long long time) set to post to itself – and that it’s nothing magic to ASP.NET. This is especially true for developers who are starting out on a new version of an existing technology – they wouldn’t know how things were before with the old version and what updates the new version has over them.

>if you ask me, most of the times when there...
One quick question on exceptions - what generally is your approach to handling exceptions? Different people have different approaches to handling exceptions and I was just curious.

- Rakesh Rajan

re: Bugs, developers and testers

rakeshrajan — Fri, 29 Jul 2005 20:47:00 GMT

What about automatic testing (like nunit, nunitasp)?

re: Bugs, developers and testers

rakeshrajan — Fri, 29 Jul 2005 04:16:00 GMT

"These are things routine developers wouldn't think about."
that's the major problem, "routine developers" that just want to get stuff to "work", developers that don't use exceptions, developers that don't stress out facts (if something should be this way, what to do if is not?) developers that assume way too many things and when the bugs arise they have to spend so many hours just to find out where the problem is, unfortunately a lot of the good new things that come out, just make programmers even lazier than ever and they can't learn how to write good robust code, and on top of everything they just blame it on MS, Windows, SQL, whatever but their code

if you ask me, most of the times when there is an error in a program I wrote (properly catched in an exception), I know almost exactly what line of code is causing the problem, that's what good exception handling gives you, that and the fact that I always stress out facts, whenever they give me a condition that something should always be in a particular way, I always reply, so what do you want the program to do if is not that way?