The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Fail Fast and exceptions

I was reading fail fast,by jim shore and was not clear about what he was saying.But,eventually i understood this..software should fail immediately when sth unexpected happen example..a parameter passed to a method is null..so method should throw exception as it cannot work without right parameter..such problems are programmers mistakes..and should be handled at global exception handler level

then,there are exceptions thrown if user supplied data through a GUI application failed business rules(if you use exceptions,some use notification)..in this case inform the user..such exceptions need to be caught to display user the error occurred..
what do you think
thks
vishy
vishy
Saturday, August 05, 2006
 
 
Generally yes. Defensive programming is waste of effort.

Depending on your language you wouldn't even do the null check because the input should be valid. In java I wouldn't do the check because it can give you a trace. In C++ I would do the check or always pass references to real objects that can't be null.
son of parnas
Saturday, August 05, 2006
 
 
If the user supplies bad data, this should be considered something expected. Give a meaningful error, and don't pass the bad (untrusted) data on to the rest of your program. Data read from a file (including the Windows registry) or over a network connection should also be considered to be untrusted, so check the data before passing it on.

Then if bad data is ever passed into a function, there is a bug in your program. In C++ I'll give an assertion (in debug code) and create a minidump (which gives a stack trace like a Java exception). The assertion lets me easily launch my debugger at that point and figure out where the bug is. The user doesn't need to know what the bug is, but the programmer does. See: http://en.wikipedia.org/wiki/Design_by_contract
DHofmann
Saturday, August 05, 2006
 
 
Unfortunately I've seen code where people took "Fail Fast" to mean "Fail utterly and totally and stop everything".  It went something like this:

catch (FileNotFoundException fnfe){
  throw new RuntimeException(fnfe);
}

Hmmm..

I do like using assertions for fail fast where programmer error is going to be the cause - otherwise I just use exceptions.  This all depends on the type of app you are building of course.  One probably doesn't need the same type of actions for failing fast on a business app than one needs for a life-critical app (in which fail totally and utterly may be appropriate).
Paul Norrie Send private email
Sunday, August 13, 2006
 
 
> problems are programmers mistakes..and should be handled at global exception handler level

I agree with logging programmer's mistakes, but for some applications you don't want a failure in one subsystem to crash the whole application.
Christopher Wells Send private email
Monday, August 14, 2006
 
 
Understanding this principle has helped me a lot,especially when I am assigning/passing objects..I just do debug.assert,and it fails immediately,if null is being passed around..
vishy
Wednesday, August 23, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz