Forum Moderators: coopster
Code may be surrounded in a try block, to facilitate the catching of potential exceptions.
[php.net...]
My question to you is, why would anyone want to allow the possibility that an exception can occur in your code? Don't you think that necessary checks and validation should be made before you do something? In my opinion knowing that an exception may be thrown and then doing nothing to prevent it from happening, but instead handling it when it does happen, is sloppy design/coding and should be avoided. This is mainly why I do not use exception handling; I am paranoid and check my data before performing an operation on it and I would encourage everyone to do the same.
Your thoughts? Similar? Different? How many of you actually use exception handling to its fullest potential when you implement a project? Just curious and I'd like others' opinions :)
Instead of thousands of IF..THEN or CASE statements, 1 or 2 exception handlers can provide the same functionality without hours of coding and without the overhead to process all those statements.
It appears to me that it has evolved as a structured way of handling unknown circumstances. Like many other technologies available to us as programmers, it can be used "properly" or it can be abused into a mess that no one wants to look at or maintain. As LifeInAsia touched on, it's a way [if laid out "properly"] to localize and generalize handlers that would have to do pretty much the same thing.
I agree with your assertion that you should validate what you're doing before you do it - I believe it's by definition part of producing a robust application. I haven't seen an instance in php that I've needed to use exceptions, but then again I've not done much with XML or anything with RSS from php. As I recall, I was barely starting to get into it when I stopped writing in C++. I'm not sure I wholly agree that it's an indication of sloppy programming. I think that if it's part of the plan, and I stress the word plan, then it can be utilized as a structured way of handling scenarios that the app might potentially encounter (unsloppily as it were <grin>).
I'm far, far from being an expert javascripter; to my albeit limited knowledge there is no way to gracefully test for an undefined variable without try...catch. Same for XML from javascript - it gets right ticked off if you try to do anything with an empty tag. It's also arguably a more robust way to test for IE/version/not IE when you're trying to set up an ajax conversation. I do have to say that IMHO these are necessary due to shortcomings in the language.
I definitely understand what you're saying, but overall I think it has its place.
unchecked: A defect in the program due to program logic - essentially a bug.
checked: Invalid conditions that happen outside the scope and control of the application, such as network failure, missing files, etc...
btw, I believe this terminology is used for Java, however, it is still relevant
At times, I understand that you cannot predict an unchecked exception all the time, so to catch the exceptions thrown would be a reasonable solution to that problem. But what of that of checked exceptions.
However, I will sometimes use exception handling during *development* to handle bugs. For example, I know about bugs A and B, but I need to fix the main issue C before I can work on A and B, so I need to use exception handling to takje care of A & B so the program (or page or whatever) gets to the point where I can work on C. But the issue is that I will (hopefully :) ) go back and fix bugs A & B before pushing things into *production*.
Um, tring to think of a good example...
OK, maybe not a great example, but let's say a partner provides content in XML. Most of the time, it's in format 1, but 5% of the time it's in format 2. I need to go forward and get the layout for format 1 content finalized so it can be approved by management. So I'll use exception handling to just ignore any content in format 2 for now. Once the layout is done for format 1, I send that to management for approval. Meanwhile, I go back and work on parsing format 2.
It looks to me like unchecked exceptions are exactly as you posit in your original post - it's using the mechanism to cover for defective, sloppy programming. I would say its only saving grace in this case is that something is better than nothing; attempting recovery with perhaps urls to click or to display "uh, we'll have to get back to you on that" is at least better than a black on white 'divide by zero error on line x of script' sort of thing where the only recovery is someone hitting a Back button (and watching it happen again :o ).
I think it's a valid method of handling checked exceptions, though, with the qualifications I stated above. Often your own code is throwing the exception in order to provide a consistent way of noting and/or recovering from the offending conditions. And, as mentioned, sometimes it's the only way to recover.
Using it during development is a completely different animal and is an excellent use which I may just have to explore!
However my question is why through an excep when your code should catch it anyway?
Yes, in some cases you can (and should) code all the exceptions. For example, user inputs 2 numbers a & B and your program does the simple task of computing A/B. WIthin the code you should handle:
- B=0
- A and/or B is non-numeric
- A and/or B is not entered
But that is a very simple example.
