A side note: wouldn't it be more convenient if it
can go on and don't
crash if it couldn't load/find the file (I mean generally, any file)? or
the functioning of mw strictly depends on every single file to run? a
safe mode or something...
But don't you want to know if something doesn't work? Your options are
either it seems to work, but then just fails when the IP-related
functions are called; or it can fail upfront, and you know that there's a
problem. The second is commonly known as failfast, and is thought by some
to be a useful property - see:
http://en.wikipedia.org/wiki/Fail-fast
(contrast with:
http://en.wikipedia.org/wiki/Fault-tolerant_system )
Personally, I generally prefer fail-fast (I'm only talking here about
non-life-critical software that I'm responsible for maintaining).
If something I'm responsible for is going to fail, then I'd much rather find out
as early as possible, than at 3 AM when an irate customer/user who has a
deadline in 5 hours runs into a showstopper bug, and demands that it be
fixed right now :-)
Equally, if a plane a going to fail, I'd much rather it be unable to take off,
than fall out of the sky in mid-flight ... but on the other hand, once a plane
is airborne, then I want N+2 redundancy on all critical systems; and once a
server has been deployed in the data centre, I want RAID to protect against
single hard disk failures.
So I suppose it really depends on :
* how critical the system is (if not very important, then the effort expended
in making it fault-tolerant may be more usefully directed elsewhere)
* whether the thing has already been deployed (in which case redundancy is
good), or whether it's being tested / developed / set up / configured (in
which case failfast is good).
-- All the best,
Nick.