Re: Allocating too much memory kills my App rather than returning NULL
Re: Allocating too much memory kills my App rather than returning NULL
- Subject: Re: Allocating too much memory kills my App rather than returning NULL
- From: Don Quixote de la Mancha <email@hidden>
- Date: Tue, 08 Nov 2011 22:44:34 -0800
On Tue, Nov 8, 2011 at 9:48 PM, Wade Tregaskis <email@hidden> wrote:
>> Simple as that, eh? Being able to gracefully handle all out of memory situations to me seems as "simple" as being required to treat every single method / function call as potentially raising an exception, and requiring the developer to add handlers + cleanup code. No existing code (OS or apps) is exceptions safe at every single line of source code. At the very least this would require a complete rewrite / review of every single line of existing source code in both OS and apps, something that seems neither simple nor practical to me.
Kids These Days.
While the Space Shuttle exploded twice, I hasten to point out that
neither of those failures was due to software bugs.
> Another straw man. We could, hypothetically, talk about the probabilities, but neither of us has sufficient data. Like most things in software development, it's up to each individual to decide where the balance is between defensive coding and whatever trade-offs it requires. My aim here has been to persuade anyone listening that this is something they have a meaningful influence over. I hope for my own selfish sake that I've succeeded at least a little, just in case I end up using code written by any of our listeners.
I don't see any particular reason why all software cannot be
completely free of bugs. It's mostly a matter of learning how to
achieve that goal.
A while back I spent a year and a half writing a very complex C++
Win32 DLL for a hedge fund. It was a specialized database kernel.
Not SQL programming, but the database itself - the on-disk storage
format, API for making queries, sorting, searching, indexing, caching
and so on.
My client emphasized that my code had to be reliable, as even a day of
downtime could cost them tens of even hundreds of thousands of
dollars.
In the six months my client spent testing my DLL before they put it
into production, only two bugs were found. I found one and my client
found one. I fixed them both before my code was ever put into
production.
A year after it was put into production, I received word from the
client's Directory of Research that no more bugs had ever been found
in my code.
How did I do that?
Mostly automated testing: unit testing, in which I tested each API of
each class in isolation, as well as integration testing, in which I
creating command-line programs that linked to my DLL, then created
databases with them and exercised my DLL from its external API.
I was using Visual C++, but I also built my code with G++ and
Metrowerks CodeWarrior to spot portability problems.
I also use assert() a great deal, mostly to check the input parameters
to functions, but elsewhere as well.
C'mon man, it's not that hard!
--
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden