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.