Exceptions - A progressive solution for OO (Score 1)

A quality solution will make good use of both exceptions and return values. Eschewing exception-based programming is rejecting powerful tools that have been made available for modern programming, allowing complex problems to be solved elegantly and in a logical, maintainable fashion.

My first example is a method that obtains the details on and individual and returns an object containing that information (name, birth, etc). The return value should be a typed object class to enforce proper communication with callers. If that method fails, it needs a way to signal the error state, why it failed, and perhaps even suggest some solutions (so an uninformed team member that is debugging will have some place to start). Since the return value type is a specific object class, the method may only return a valid object or a null value. It could return null indicating an error and forcing the caller to then query for the reason for the error, but this creates additional calls and complexity (which would be particularly poor when attempting to scale to a distributed application). The simpler solution is to throw a specially tailored exception of a type appropriate for the error. The exception can hold the reason for the error, the stack trace, suggestions on why it failed ("unable to contact server - make sure network connected"), etc. Now the caller can ask for an individual and receive it, confident that the returned object is indeed an individual, and if an error occurs, the exception can be caught and either passed up the chain, or handled on the spot with far more information than a single return code could provide.

My second example is a method that receives a few numeric values and returns a calculated integer, arrived at through some complex formula. There is a potential for errors to occur due to incorrect, invalid, or out of range input. The valid response could be any positive or negative integer, or zero. You could pre-test the values to validate them, but then either the caller has to understand what the method does (bad encapsulation), or you have to make separate call(s) to the object providing the method in order to first validate the input (bad scalability). Again the ideal solution is to simply validate the input within the method, throwing an error if it does not meet requirements, and otherwise computing the result (throwing math computation errors if any occur), returning the final value. If no error is thrown, your program continues along secure in the knowledge that the returned value is not an error code. If an error does occur, the caller can easily branch to the correct handler to tell the user the input was invalid, or log a math error, etc.

In my opinion, as a real professional, it is foolhardy to dismiss this very useful advancement in technology.

Finally, to respond to the original question, I agree with many of the other posts in that the control and service in question may be useful to save a few or several hours of work for small applications, but for any application that intends to be competitive, it would be better to self-host end-use error reporting services.