Re: Bit flipping .. will this work in VB6?

Tech-Archive recommends: Speed Up your PC by fixing your registry


"Larry Serflaten" <serflaten@xxxxxxxxxxxxxx> wrote in message
news:uPbSPqffIHA.5296@xxxxxxxxxxxxxxxxxxxxxxx

"Michael C" <nospam@xxxxxxxxxxx> wrote

Why did they add bugs to their code? What purpose does that serve???

Bugs are present in any project of significant size.

I've read what you said, and will refute anything to the effect that I
said
error handling should be avoided in the entire application. I merely said
that if you add the err.raise command, somebody (somewhere on the
callstack)
has to have that routine wrapped in an error handler. By adding the Raise
command you force someone to trap that error or let the program crash.

But I think the main point of contention we have is from the statement
above. You claim bugs are inevitable, I'd say they aren't. Way too many
people use that philosophy to support their 'ship now and fix it later'
schedule.
And I can appreciate that for most 'run-of-the-mill' coders, it would take
too
long to try to write code that won't fail unexpectedly. But it can be
done.

If you don't attempt to reach that goal, then you'll never attain it.

That's not to say there aren't going to be problems along the way, errors
that need correction or debugging, but experience gained while striving
toward that goal will help to giude the designs and coding style needed
to avoid writing so many bugs. Working through the pitfalls and dead
ends, and what not, (replacing failures with more stable code) causes
one to gravitate toward writing the more stable code the first time
through....

LFS


Larry, you are absolutely correct.

1) Delivered components/modules that Raise Errors to parents are problematic
within a Team environment unless the Team or Enterprise have formally
adopted such a strategy and the author is fully aware of the consequences.

But this is seldom a serious or chronic issue, as any problems quickly
reveal themselves and are resolved.

2) Any enterprise, team, or programmer that accepts the philosophy that
"bugs are inevitable" find their philosophy to be valid and well documented.

This is always a serious and chronic problem and difficult (if not
impossible) to resolve if challenged head-on. It takes time, attention to
detail, and incrementatl replacement of bad habits with better practices.

-ralph


.

Relevant Pages

  • Re: Patching the VCL
    ... > priority to resolve it (regardless of reproducibility). ... > been in existence for a while then the priority gets elevated even more. ... There are some dangers with such a philosophy. ... handful of reproducible and some old lingering bugs that appear sporadically ...
    (borland.public.delphi.non-technical)
  • Re: Language enhancements
    ... > the philosophy that then the behaviour of the called method is ... Hmmm. ... But doesn't that lead to bugs? ... Falafel Software http://www.falafelsoft.com ...
    (borland.public.delphi.non-technical)
  • Re: BDS 2006
    ... That is the build number for BDS 2006 update 2. ... If the reports that they ... base to resolve these reports. ... So 27 of the 33 user reported bugs that were marked as resolved by update ...
    (borland.public.delphi.non-technical)
  • Re: The Borland Vision: Wrong?
    ... > will, at the end of the day, resolve your problems? ... for it and address bugs and issue SPs. ... defence of Borland for not fixing bugs (in the thread 'QC in place to humour ... and applaud Borland for that rather than complain that other bugs developers ...
    (borland.public.delphi.non-technical)
  • Re: QC in place to humour developers?
    ... >> fixed some of the other bugs'. ... > Borland on these newsgroups, in the face of overwhelming evidence to ... bugs rather than trying to address and resolve all bug reports seemed odd ...
    (borland.public.delphi.non-technical)