Printable View
Frankly I think it is stupid as compared to VB and other MS technologies. But I am still curious.
Can anyone tell me the logic behind creating separate classes for each type of error, instead of creating a general class Error with error numbers for different types of errors?
.
That way, you can define your own errors. Actually, throwing exceptions is far superior to VB's style of error catching.
Java is based on the Object Oriented Paradigm. If you don't want to take advantage of this design, you can still handle errors (or rather Exceptions) with the parent datatype java.lang.Exception. You may also write all of your code in only one function named "main".
You cannot (or should not) handle errors which are deemed unrecoverable or abnormal and are of the datatype java.lang.Error (the analogous Fatal Error). I suppose it would be nice if the infamous blue screen of death would flash up and inform us that the entire OS is unstable, forcing a cold boot; then have scandisk run on reboot saying that we should have shut down properly.
I find being notified of an UnsupportedAudioFileException a step in the right direction as opposed to "error 12321". But if you need to see a number, you can certainly add it.
You also can create your own Exceptions by subclassing a particular Exception datatype. That can come in handy for your customized data structures and/or customized processing methods (to name a few applications) -- along with a more descriptive message/explanation of the error.
Also, handling an error can become more specific by its type. I suppose the same could be accomplished in MS apps by having all errors numbered in the range 58000-58999 being a certain type error. But I'm sure you'll agree that the thousand slots run out quickly with MS apps. As the need for more error types expand (as is surely the case for MS), MS would have to include grouping another range, say 234000-259999 as being of similar type to the range 58000-58999. Eventually, developers would require a regrouping so that they would appear in the same range to process more efficiently.
Frankly, I don't think the Java OO method is stupid. It is good that you are curious.
When all the properties of the various error objects are the same, why to create separate classes? It is much easier for e.g. in VB to raise your own errors. Just use the Err.Raise statement with a number. Convention has that you should not use the built-in error numbers, but nobody has stopped you if you want to.
There is a point, however with MS products quickly reaching the limits of the built-in error numbers, but there could be a workaround to that problem.
Besides, the MS technique still preserves the error class, so it should not be against Java's method of 'class'ifying everything. Simply a new instance of the Error class and you are done.
Imagine the overheads if I have to write a component in Java for some complex operations, and have to throw about 5 different types of errors. I shall have to write the classes for all these five error types and then in my application, an equal number of catch statements, one for each error, under ideal conditions.
To generalize the error-catching, you can even use the Throwable class in the catch clause, but that's not the ideal way.
The only part I think is great is the finally clause. But with a little coding, the same can be imitated in VB and other languages which allow error trapping.
.