2009-09-30, 09:25 PM
There are pros and cons to Exception, and personally, I think Java overkilled it.
Tho, that is not necessarily a bad thing. It forces you to be aware of "issues". If we're going back to the PNG class and ImageStream interface we talked before, lets look at a few scenarios.
1 - the function get_data in ImageStream failed to return the correct data. Sure you can code the function to have a massive if elseif else statement to govern all the possible cases, but it's an Interface, so each implementation has to carry out this task independently.
If you turn it into an abstract class, that would solve the implementation issues, where only one implementation exists, however you're losing out on extending, because you can only extends once.
Alternatively, you can apply a decorator/observer to the ImageStream, to handle errors.
2 - you want customized error messages. In many situations, you will face an issue of how much information to display. Say you're using the above code to generate an image on the fly for sp.net users to view. Surely if something goes wrong, you want to tell them that it has "Failed to display the requested image", but tell yourself (in an error log file) that "OMG line xxx has a bad byte in it so I cant get the data out of file yyy after executing function zzz" etc to help you debug more.
You may jump at the gun and think "INHERITANCE", but you're effectively entangle more of your code unnecessarily. Alternatively, you may want to use printf to control the format, or have the error writes to a stream, but again, extra weight.
This is where exception comes handy. Coding logic should be "code to work, branch out errors". In OOP, Exceptions are vital when used correctly. In the first scenario, you can return appropriate exceptions per error or error groups. This ensures that the code does its checking. Tho you're still facing extends only 1 class issue. Once received an exception, the caller may choose to either throws it further up or digests it. Whether it be a log, or how much to display, etc, the decision is up to the caller, which is how it should be.
If you take the MVC framework for example, the Model can run the business logic, and throws out either a result or an exception, which the controller receives and asks the view to render the appropriate display. Without exception, the Model must always keep its state in a pair {success/failure, data/error}, and the controller must check for it all the times.
Further more, you will need to define your own error code, and have the view anticipates this flag as well, to display customised errors. This is seen regularly in C codes.
tl;dr;
Exception is an advanced form of error handling.
Tho, that is not necessarily a bad thing. It forces you to be aware of "issues". If we're going back to the PNG class and ImageStream interface we talked before, lets look at a few scenarios.
1 - the function get_data in ImageStream failed to return the correct data. Sure you can code the function to have a massive if elseif else statement to govern all the possible cases, but it's an Interface, so each implementation has to carry out this task independently.
If you turn it into an abstract class, that would solve the implementation issues, where only one implementation exists, however you're losing out on extending, because you can only extends once.
Alternatively, you can apply a decorator/observer to the ImageStream, to handle errors.
2 - you want customized error messages. In many situations, you will face an issue of how much information to display. Say you're using the above code to generate an image on the fly for sp.net users to view. Surely if something goes wrong, you want to tell them that it has "Failed to display the requested image", but tell yourself (in an error log file) that "OMG line xxx has a bad byte in it so I cant get the data out of file yyy after executing function zzz" etc to help you debug more.
You may jump at the gun and think "INHERITANCE", but you're effectively entangle more of your code unnecessarily. Alternatively, you may want to use printf to control the format, or have the error writes to a stream, but again, extra weight.
This is where exception comes handy. Coding logic should be "code to work, branch out errors". In OOP, Exceptions are vital when used correctly. In the first scenario, you can return appropriate exceptions per error or error groups. This ensures that the code does its checking. Tho you're still facing extends only 1 class issue. Once received an exception, the caller may choose to either throws it further up or digests it. Whether it be a log, or how much to display, etc, the decision is up to the caller, which is how it should be.
If you take the MVC framework for example, the Model can run the business logic, and throws out either a result or an exception, which the controller receives and asks the view to render the appropriate display. Without exception, the Model must always keep its state in a pair {success/failure, data/error}, and the controller must check for it all the times.
Further more, you will need to define your own error code, and have the view anticipates this flag as well, to display customised errors. This is seen regularly in C codes.
tl;dr;
Exception is an advanced form of error handling.