What did exceptions ever do to you?

I was doing my daily browsing of the sitepoint forums and was visiting a topic we have started regarding Hibernate and OQL. One of the posts in that topic said pretty much the following:

[quote]Oh i forgot to mention that Exceptions are a prime example of something that doesnt fit the PHP way at all![/quote]

Now I don’t exactly know what the "PHP" way is. But a statement like this makes ABSOLUTELY no sense to me. I decided against posting my thoughts at sitepoint as this would undoubtedly ruin an otherwise informative thread.

Now thankfully I was able to get a better idea of where this guy was coming from since he posted a comment at the following blog post:

http://blog.thinkphp.de/archives/14-ReflectionClasshasMethod.html.

Read on….

Unplanned OOD = Planned Disaster

Quite frankly, after reading his post what he said in it makes no sense to me. Since when does PHP have to be a rapid application deployment tool? I will admit that it fit that bill pretty well back in php4. However, I thought the intent for php5 was to cater to object oriented designers and quite frankly if you intend to just launch yourself straight into programming completely undefined or unplanned interfaces you are going to have a somewhat ineffective and unscalable program resulting. I will agree that there are some types of people that put waaaay too much emphasis on modeling. However to completely ignore modeling means you will be designing as you go and that will often lead to lots of code rewrites and headaches down the road.

Lack of a model makes unit testing harder. How can you write test cases without knowing what you will be testing? He mentiones that the real problem in programming is to get the interface to the user just right. Now I don’t exactly know what this means. In either case how can you tell exactly what the user needs without first determining a model that will fit the user’s needs? Surely you wouldn’t write all the code and then say "Does this work for you?" What happens if they say no? You basically have to go through a large chunk of the development process all over again.

One good point he did make was the lack of OOM tools for PHP5. Compared to Java PHP5 has pretty much nothing in the realm of OOM tools. I don’t see this remaining the case for very long however. I estimate by the end of the year php5 will have become mainstream enough to warrant the attention of some of the UML tool creators. I would wager to guess someone, somewhere has already started a PHP5 add-on for Poseidon. There are also plenty of tools out there that can speed ub development such as Phing, Propel, SimpleTest. So just give it some time and OOD in PHP5 will be as close to painless as possible.

Also, it is not our job to explain UML diagrams to customers and it’s not their job to understand them. Interactions with the client should be done through phased releases. To expect them to understand all of the "programmer’s lingo" is arrogant. If there isn’t someone on your design team who can communicate with a client in terms they can understand then it’s time to hire some new team members. I understand wanting to get a full prototype out to a customer, but this just seems like a recipe for disaster. Why not just take the time to plan one phase of the project then while you are developing that phase have someone else (or even do it yourself when you get bored with coding) start another phase. The requirements and interface for the first phase components will already be set so there is no reason not to start planning while coding.

[quote]
Ok it seems I have gone off on a tangent. So wy are exceptions bad? Because they force you to write finished code. Finished bug free code. But that means you cant quickly make some modifications to your application to help your users become something that feels a bit more like what they have in mind. They dont need bug free code for that. They need to be able to see and touch the prototype in regards to the specific thing you are currently trying to visualize for them. Even if that means that you have an error string in a dropdown instead of a list of all countries that should normally go there.[/quote]

Why not write finished bug free code? I would rather be able to hand a client a piece of working, bugfree, finished code before I ever gave them a prototype that really doesn’t do a whole heck of alot. If you can’t code around exceptions and come up with working code quickly than you have some serious problems that need to be addressed.

I don’t think I was very clear here when I wrote this. When I said I didn’t want to give them a prototype that doesn’t do a whole heck of alot I was referring a functional prototype. I will quite commonly give the client a presentation prototype that will show them what their app will look like. Similar to how you would pass a client and empty shell of a GUI in software app development. While no real functionality is involved I do include descriptions of functionality. For more info take a gander at the first comment I posted.

Why Do I Like Exceptions?

Well, the biggest reason is it helps you seperate your code. I remember many days spent in php4 trying to tie an error handling class into my application. Then I would run accross someone elses code that I wanted to integrate and it handled error handling completely different. There was no elegant way to recover from non-fatal errors.

Exceptions in php5 now solve lots of problems. It gives developers access to a widely used and widely understood and highly compatible interface by which to handle error management. It is extremely simple to recover from non-fatal errors. It is also extremely effective at validating input. It makes it easy to keep error generation within the domain/data acces/etc. layers while keeping the error handling within the application layer where it belongs.

Well, that pretty much wraps up a broad overview of my thoughts on this matter. While I’ll agree that you can use exceptions badly, I fully disagree that there isn’t a place in php for them.

20 thoughts on “What did exceptions ever do to you?”

  1. Hi :-)

    Well the question is why bother with PHP? Why dont you just use Java and all the cool modeling tools? The second you use modeling tools it becomes kinda pointless to argue about ease of use in glueing things together. After all a large chunk should be handled by your code generator. And here PHP will take ages to catch up to all those defined interfaces that are around in Java.

    Anyways, I can tell you that my way of developing is incredibly successful. And let me take another stab at explaing how it actually works.

    What I mean with the “interface to the user” I mean the actual workflow the user has to follow. Where things are located. What he sees when and where. No mockup pictures and certainly now state chart will tell your users anything. They are 100% unable to think in abstract terms. So anything you give them makes things concret. Of course until you are finished all you can offer are pieces. But since they are able to interact with these pieces they can say what they are missing.

    Remember: “code is law”. Whatever your code does or doesnt do becomes the law for the user. However its absurd if you define the laws in code and there is no way to make the user understand the laws that have are being implemented with anything but some sort of prototype. This is my experience and you seem to believe that too. What I give my communication guy are hands on prototypes he can take to our client. Often I sit next to him and make changes to the application in real time to help visualize what they are talking about.

    The big challenge of course is getting proper code in the end that is actually maintainable. I have used a bit of unit testing there (I am planning to use more, but as my main application is very high on database interaction and timed deadlines its quite a challenge to handle things as I end up having to implement stuff like mockup objects etc.) Basically it means going through the code on a regular basis and cleaning things up.

    I have a clean framework as a basis. So the application specific logic tends to be usually distributed across 3-5 modules each with about 1k-5k LOC and about 10-20 config files.

    Another key challenge is identifying the tricky parts quickly. So that they get tackled first. Of course I am often faced with rapidly changing final goals. So it s tricky but doable.

    The thing that we havent been very good at so far is getting the documentation done in time since we get change requests fairly late in the game quite often. But that is a problem we can overcome by simply putting more ressources into documentation which we have failed to do in the past.

    So to conclude:
    The idea is to get a somewhat concrete prototype into the hands of the client ASAP .. whenever new ideas and challenges popup. Exceptions will slow down this process as its likely that due to Exceptions being thrown large parts of the application will not display anything. The job of a prototype is not to be bug free, but the job of a prototype is to require as little time as possible to get an idea into a test application.

    Also if you want 100% bug free you can simply define a global error handler that will give you the same effect. The error handler will be called as long as you are not 100% bug free. A backtrace and/or debugger will let you pin point the location of the bug just as quickly too.

  2. Wow, you found your way back :). I’m glad you responded. This is alot clearer than the explanation you posted on the other blog :).

    As far as why I use PHP instead of Java is mostly because of how things are where I work. While I am extremely fond of Java I am not really to keen on jsp. However, I think the same kind of programming methodologies can apply. Are they always necessary? Probably not.

    I still do have to disagree with your view about exceptions. I suppose this could come from the differences in how we use and have seen others use exceptions. The way I like to work things the only exceptions that wouldn’t display anything would be unhandled exceptions. My goal in life (well..you get my drift :)) is to leave as few as possible exception unhandled. The way exceptions work make this extremely easy to do. If you absolutely have to you can have a “catch-all” exception handler that would be able to catch an otherwise unhandled exception, do whatever you want with it, and redirect the user to an error page.

    I am not quite sure I am on the same page with what you are trying to convey yet.

    As far as prototypes: Many times, to give our client a picture of what their full application will look like we will create a static mock-up of sorts for their web app. When needed the prototype will have description of associated functionality such as “Clicking this button will send an e-mail to this individual” or “The product will be added to the users cart.” Very little programming effort goes into this prototype. It also usually forms the basis for our presentation layer when we actually do start the programming. I suppose I should have mentioned these details in my original blogging, but I was thinking more along the lines of a functional prototype. In any case I still maintain that trying to create a prototype early on with too much functionality is kinda like putting the goose before the gander. Either way you break it down both methods apparently worked.

    As far as the error handler…why build a global error handler if I can do the same thing with internal exception objects :) :) :) (I know, now I’m just being brash)

    Again, thanks for the response, I really do appreciate it and your thoughts make ALOT more sense to me now :).

  3. Obviously our method is inefficient due to lack of a global plan. We do safe a bit of time since our prototypes actually eventually will become the final application. So the itme invested in the prototypes usually pays off quite directly.

    However the main advantage I see in our style of development is that in terms of getting things just right for the user our first release is usually right around where version 2 or version 3 of most other development teams are. This gives us the necessary time to clean up our code while other development teams are doing work on their next major version. Another key advantage with our development style is that the client is less worried that things will not materialize in time or when they dont he can be warned much better.

    The development style obviously doesnt work at all if the client doesnt want to be involved with the development process. And this is a key point. Without the client being willing to look at all those prototypes obviously you loose out on all the advantages.

  4. I do acknowledge that you do have a good advantage when it comes to showing the client “stuff” early. As far as usability of the first release, we usually have the same kind of success with it as well. However, like I said before it takes a bit longer for the client to see anything usable as far as functionality. Occasionally we can compensate for this with the “phased release” mentality.

    We have actually been having the “eye-candy” problem with clients lately. We are pretty anal (sometimes moreso than we should be imo) about knowing all the requirements before getting into the prototype. However when we are finished the client is usually thrilled with what they have recieved.

    I am actively working on a new framework that we will use in building some of our future projects around that will speed up alot of our development via code generation and other similar techniques. It is a PHP5 framework and of course it uses exceptions ;). I designed it around a Domain Model/Data Mapper pattern and have actually finished an initial build of it. It also utilizes some home grown code generation tools. Some test runs have yielded very promising results as far as run of the mill web app databases go. So we will soon be able to get the persistence portion of things done very quickly. This’ll obviously shorten the time between presentation prototype and final release as I will only really have to worry about implementing the domain rules and the front controllers.

    In any case, you are right you do have some significant advantages when it comes to speed of releasing the first “goody” I do think it evens out over time, but we all know how patient end users can be :P.

  5. Eitherway .. great to see that people on both sides of the exception paradigm can have a sensible discussion, but the merits of the other side :-)

  6. Quite true…also it’s the most comment traffic my blog has ever seen in one day :).

    I do have to say I can appreciate your position on design before development more after thinking about it. You’ll still have to rip exceptions out of my dead lifeless hands though :).

  7. Now at least I know why some people seem to “hate” exceptions in PHP, while in the other hand I’m eager to seeing PHP5 implemeted in my webhosting service, which is not yet because of some problems with old scripts the clients of the webhosting service are using.

    Well, it turns out the reason behind exception rejection by a lot of people is because when an exception is thrown, it “skips” (or bubbles out) your code instead of executing the next executable code, right? So in “unplanned” (i.e. without a try-catch block) function call, when an exception is thrown, your “entire” (i.e. as long as nobody catches the exception) script will fail, and all is left is just the error message (if error reporting is turned on).

    I find that this is actually the way it should work. I you NEVER expects for an error, then when an error happens, well you must live with it! The idea behind exception handling is that you must EXPLICITLY declare that you EXPECT an error to happen, or you leave error handling to “somebody up there” which “knows” how to handle a particular type of error. Usually, the uppermost level (or the default exception handler, or whatever) should display an error page when there is an uncatched exception. This works in Delphi, C++Builder, Visual C++, even when they have no automatic garbage collection. These “bubbling out” may mean memory leaks in these programming environments, if code is not properly coded, i.e. if you create an object and after that an exception is thrown and unhandled, the bubbling will mean that the object will never be freed, right? Well this requires the coder to have proper try/catch (or try/finally) statements so that when exceptions are thrown, the objects are properly deleted.

    Now forgive my attempt to go into the “other side” of the world. It turns out, IMHO, that the languages which “invent” exceptions are somewhat more complex when exceptions are involved, than in PHP. In Java and PHP, you never need to handle unfreed objects when exceptions are thrown, isn’t that a luxury? Now you say “my script terminates when an an exception is thrown”. Well, I guess there’s something you should do, either you should prepare for the exception, or wrap the function that generates the exception (even if other called functions throw the exception) in an empty try/catch block.

    I’ll let myself give an example:

    $ids = $_POST[‘ids’];
    try {
    foreach ($id in $ids) {
    doSomething($id);
    }
    } catch(Exception e) {
    logError(e);
    }

    (I’m sure that my try/catch syntax is incorrect, since I don’t know the PHP5 exception syntax, only that I know it exists)

    Now, why is it so hard to have an empty catch block like my example? In traditional way, if an error happens with doSomething(), either a lot of error messages will be printed, or it will display nothing. In both cases you lose.

    With the “silent” try/catch block like my example, once an exception is thrown, it will bubble out to the “nearest” catch block, and well, it handles it silently, by just logging the error. Since it does not reraise the exception, your script continues to function “properly” (in case the exception does not affect other parts of the script, of course).

    I really am not against anyone who likes the traditional error handling (whatever, using PHP’s error handling or PEAR_Error, or any custom invention). But I think that anyone who thinks that exceptions are not for PHP should really study exceptions more. IMHO, they are very suited to PHP. Even JavaScript uses exceptions! When done correctly, exceptions are the best way of handling errors. When they say exceptions are “goto-ish” or “bubbles out arbitrarily” should really check the code. The problem is not whether exceptions are good or bad, but whether you use it correctly.

    As to draw a midline, you can always use both, or prefer to “avoid” exceptions. If you use a package or library which uses exceptions, and you’re afraid that using them might cause your script to terminate unexpectedly, well, then always wrap your calls inside empty catch blocks. Or if you prefer, use trigger_error() inside the catch block (assuming you don’t have a custom error handler).

    Hmm did I comment too much? I might as well start my own blog… 😛

  8. I still dont see what additional advantage they offer. I like PEAR_Error alot. Since it lets me locally define that the global error handler should be ignored. However all unexpected errors should be handled during development before you hand over the final code. And for that you dont need exceptions, you just need a global error handler that jumps in your face until you fixed the issue.

    Now when we turn to prototyping I turn of the global error handler and log to a file.

    Finally for production I do essentially the same. In some cases you might however want to die() gracefully on error. And here again a global error handler works nicely. If you want to just hide the output from the module that caused the error things get more interesting. This is the only situation where automatic bubbleing out might be feasible. But I never felt a need for this. Actually I just thought of this scenario just now. So I will ponder it a bit more

  9. BTW: Suggesting to wrap every library call to all exception using libs with an empty catch block is obviously a rediculous suggestion and slightly offending without a smilie.

  10. Thanks Lukas for responding so promptly! :-)

    Actually I tend to believe you more than myself, since I’m not that experienced. It’s just that I came from Delphi world before I jumped in to PHP. And since I was so used with exceptions (I was more familiar with try/finally than with try/catch), I was very disappointed that PHP (that time still version 3) didn’t have exceptions. And when PHP4 came out, it still didn’t have exceptions. Now when PHP5 have exceptions, it’s still not installed in my webhost and I found too many people complaining about exceptions in PHP… now I’m getting confused (that’s why I’m trying to understand here).

    So I did try to read other blogs, sites, and articles, about this exception-thingy, not just in PHP but also in other languages (most notably C++ and C#). And experts say that coding correct exception based code is really hard. Hmmm… now that I just know. They say it’s harder than traditional (error-code) handling? Now I can’t understand this. Exceptions are supposed to make people’s lives easier (as I think they do to me). But why is it considered harder?

    I haven’t delved deep into PEAR_Error, even though I use it in my code I don’t really check for all its features. But when you said “I like PEAR_Error alot. Since it lets me locally define that the global error handler should be ignored.” do you mean the caller function can “ignore” (i.e. handle errors locally) any global error handler when calling another function that raises a PEAR_Error?

    I mean, it’s possible to raise a PEAR_Error error which overrides the default error handling mechanism (callback, trigger, etc.) but I don’t see a way of overriding this on the *caller* level, other than calling PEAR_Error::setdefault-like function (I don’t recall the name) but this means we have to restore the default error handler after we’ve finished our local error handling.

    About “Suggesting to wrap every library call to all exception using libs with an empty catch block is obviously a rediculous suggestion and slightly offending without a smilie.” I completely agree with you. Do you know a more elegant way or “ignoring” exceptions? Since turning off exceptions would be the worst I can think off, i.e. it’s not exception-compliant anymore. And empty catches are the closest I can think of when we need silent exceptions.

    I’m interested in this exception-thingy, if you’d like to give references to other sites I’d be so happy to skim through them (if they’re related, of course).

    If you think it’s not good to debate in other’s blog I’m welcoming you to e-mail me in private. Actually I’m not asking for a debate, as I’m just trying to understand (deeply) why other people think exceptions (specifically in PHP) are bad. While I think exceptions are better than traditional error handling, I also think that traditional error handling is NOT bad, and there are some cases (though I think should be very few) where exceptions cannot replace traditional errors.

    I also commented here:
    http://paul-m-jones.com/blog/index.php?p=105

  11. Thats one of the key points:
    You cant disable exceptions. They are either caught or bubble out of the scope until you end up with a fatal error. I so its obviously limiting in flexibility.

    The question now is mostly around do you care about this loss of flexibility. I do.

    As for PEAR_Error .. its a work of genious in many ways imho. PEAR_ErrorStack builds on its ideas but I havent yet become as intimate with it as I am with PEAR_Error.

    So basically with PEAR_Error you can set a global error handler:

    PEAR::setErrorHandling(PEAR_ERROR_CALLBACK, ‘handle_pear_error’);

    Now the interesting bit is being able to locally disable the global error handler for specific errors. The best example is the nextID() method in the PEAR::[M]DB[2] libraries.

    This piece of code runs a query and expect that the table for the query doesnt exist. It then goes to handle the error condition locally by checking the code of the error object:
    $this->expectError(MDB2_ERROR_NOSUCHTABLE);
    $result = $this->_doQuery($query, true);
    $this->popExpect();
    if (MDB2::isError($result)) {
    if ($ondemand && $result->getCode() == MDB2_ERROR_NOSUCHTABLE) {
    ..
    }
    }

  12. geese…blog one little thought and look what happens :).

    Well, there are a few things I disagree with. The first being that exceptions aren’t flexible. I don’t quite understand why you are saying that. In your error handling schemes you mentioned you usually just log your errors to a file. This is just as possible with exceptions. just log the error inside of your exceptions. Also another thing that exceptions offer is a way to easily recover from otherwise fatal errors. One thing I would agree with is that many open libraries do misuse exceptions in ways that are entirely annoying. For instance, I have yet to run across a library that extensivly documents their thrown exceptions. This almost renders exceptions useless imo. Others tend to never associate a code with their exceptions and instead use just error messages. When I am trying to determine how to handle an exception it is far easier to match a code than it is a string. (okay so maybe not really…but I won’t have to type as much.) Those two tendancies do make exceptions a pain in the but. However, just like the link you posted in your last comment states, just because people can use exceptions wrong doesn’t mean they should be discounted.

    If you aren’t comfortable and you don’t want to become comfortable (or you simply don’t see the need to be comfortable) with exceptions then why even bother using them. I think standard error handling and exceptions are both valid ways of handling errors. I do think it’s unfortunate that there two completely different camps on this as it makes integration of various libraries more difficult, but I do think the introduction of exceptions into php5 was a good thing. Maybe I will try to dig up some good links on the “right” way to use exceptions. That’d be a good weekend project.

    Also, please don’t be afraid to discuss such things here. I welcome open discussion in my blog as I believe it can only help the community to see two sides to the argument. Keep it civil and i’m fine with it. So keep up the discussion :).

  13. Hi Mike!

    Glad to see the owner of this blog comments on its comments.

    >The first being that exceptions aren’t flexible.

    Even though I’m on the side on exceptions… I have to agree with Lukas on this one. I have yet to find a way on how to properly “disable” exceptions.

    I mean, when we code using exceptions… we know one thing for sure: “When something bad happens before this, this code won’t be executed, and this is the behavior I expect. Somebody up there with a catch block will deal with it. I don’t care.”

    Now… there are times when somebody (I guess not me) wants the code to work as if no exceptions are thrown. i.e. just display the error message and continue the script. A rather real example would be if something’s wrong with my header, I don’t want the entire page to fail, but I rather see that error message in my header, but the rest of the page continues to work fine.

    An imaginary global-level exception handler would be like this:

    try {
    Application->Run();
    } catch(…) {
    echo GetLastErrorMessage();
    continue;
    }

    That “continue” statement would reverse the bubbling out process…. in that it “bubbles in” to the code that raised the exception… and continue executing the following code!! I’m not sure if PHP 5 implements this, and I’m not even sure if any other language has this “weird” feature. I think it, if it actually exists, is a more presumably disastrous feature rather than useful, but can provide the “flexibility” that I (and Lukas) say lacks in exceptions.

    >When I am trying to determine how to handle an exception it is far easier to match a code than it is a string.

    For me though, I prefer exception classes. Actually exception subclasses. I guess it’s more useful than error codes since some error codes belong in a particular “class”. Instead of handling DBERR_NOTABLE, DBERR_BADQUERY, and DBERR_BADSYNTAX, I would rather handle DBException, which is extended by DBNoTableException class and so on and so on. So you can intercept whatever kind of exception you want. Since the “error code” forms a hierarchy, it’s easy to pick which ones you want to catch. Even if you want to catch every exception, it’s easy to know what kind of exception it is (granted, get_class(exception) returns a string, but it’s more fixed than a real string, and you can use is_a, is_subclass_of, etc.)

    With error codes you can use bit operators if your error codes are specially designed, i.e. 1, 2, 4, and you can have & 7 to catch all the three errors previously mentioned. But this has its obvious drawbacks. And well you’re limited to 32 bits. With Exception objects you’re also free to add your own member variables. This can be done with arrays but objects have a class (which is useful for determining the type of exception), and arrays don’t.

    >with exceptions then why even bother using them

    What you said is true… but not using exceptions means not using libraries which use exceptions, and this is not preferable. So, if Lukas “hates” exceptions, and somehow he uses a library which extensively uses exceptions (and throws exceptions EVERYwhere), even though the exceptions are excellently documented (though this case is rare)… so what can Lukas do? Weep in tears? Try to put try/catch blocks everywhere???

    This might not be a serious problem if that library is used by only one script. But what if that library is a DB engine? And every call to DB::query() has the possibility of throwing an exception? What if that query has a DBNoRowsFound exception?!? An exception if the query returns no rows!??!? Now that’s bad… and somehow overextremed, but it’s possible. I have 1,024+ DB::query() calls in my scripts and I have to do a try/catch block for ALL of those? Wow, that seems too much work. If only I can “bubble in” (like what I stated above).

    Ok, one solution I had in mind would be to wrap the function call in another function call which uses an empty catch block. Lukas thinks this is ridiculous… I agree with him, actually I’m not recommending to do that (I never had an empty catch block, at least I’ll log to something even if I ignore the exception), but since I can’t find a more elegant way of “avoiding” this problem could Lukas give me the more elegant way…?

    But the solution is only suited if you need to wrap one function. If you need to wrap 100 functions then you’ll need something like call_user_func wrapper with an empty (or whatever) catch block.

    > Maybe I will try to dig up some good links on the “right” way to use exceptions.

    When talking about exceptions, I think Java does it best. As far as I know Java only lets you throw an exception that you declared on the function declaration (correct me). This is a good thing. When a function declares no exceptions, it means that you’re “safe” to use that function, as long as no other functions that this function calls raises an exception. But this is impossible in PHP, due to the dynamic nature of functions, even included files.

  14. You can ‘kinda’ program libraries with exceptions without even needing to use try {} catch {}

    check out this link: http://www.php.net/manual/en/function.set-exception-handler.php

    As far as continuing code after an exception…properly placed exceptions should only be issued when you have a situation that would hinder code from processing further. For instance, a needed file is missing, there is an error within an sql query etc. So while continue withing catch blocks might be a good idea, i could see it as opening an extremely nasty can of worms. (some may argue that it would be no nastier than the can that exceptions themselves offer :).

    As far as documented exceptions, I agree that most if not all :/ php projects lack decent documentation for the exceptions that are thrown. I don’t think that is the fault of php or the exceptions system though. The blame for that should rest squarely on the library developers shoulders. Just because the code isn’t necessarily ‘self-documenting’ doesn’t mean it can’t be manually documented.

    I have alot more I would like to type out but I am on my way to go out to lunch. I think instead of finding links I may write my own article. I have yet to find a decent article that makes the points I want to make using php (there are lots of java ones….just goto onjava.com :))

    Oh and thank you for your kind words :). I visited your blog but unfortunately couldn’t understand a word :). I need to take some language lessons I guess 😉

  15. the set_exception_handler is nothing but a global error handler that evades the uncaught exception fatal error. You still have unraveled your entire stack and cant continue execution at the point where the exception was thrown.

  16. Like I said before, properly thrown exceptions SHOULD halt your code because they are throwing an alert of sorts that is basically saying that something is happening in your code that shouldn’t. A good example is an SQL error. If using a Database Abstraction Layer that uses exceptions, chances are an exception will be thrown containing the sql error. Why would you want to ‘step over’ this kind of error?

    The fact that you can’t turn exceptions off in code that uses them may be inconvenient but it isn’t inflexible. Again, there is alot of code that misuses exception and therefore exacerbates the inconvenience to the point of being inflexible. The better libraries will basically use exceptions to ensure that you are using the library properly and to ensure the system is running as expected. Neither type of exception (or error if you will) should be ignored, they reveal inherint flaws in the implementing system that should be fixed.

    Even if you consider the inability to deactivate exceptions an inflexibility, exceptions provide much more flexibility in areas that conventional error handling does not. The biggest areas of flexibility are the ability to pass additional information with the exception, the ability to seperate the handling of exception into the correct portions of code that SHOULD be handling the exception, and the ability to handle a single error in multiple subsystems.

  17. Mike wrote:

    “Again, there is alot of code that misuses exception and therefore exacerbates the inconvenience to the point of being inflexible”

    If you want to see the nightmare that will be exceptions in PHP, take a look at how well-respected apps are doing error handling now.

    I guarantee that PHP users will neither

    1) use error codes
    2) extend Exception with their own classes

    unless they are forced to. Why is this important? If you want to use code from many different sources, and ALL of them use the generic Exception class with only error messages, then you have 3 choices:

    1) parse error messages and never upgrade in case the author of a package decides to fix the grammar of a message
    2) rewrite the offending code in your own hand
    3) curse, and use another programming language

    Basically, those who argue that exceptions are beautiful are missing the point. PHP programmers are lazy. Their code is ugly. This is a good thing because the language is designed to be stable and easy to code quickly. Programmers attracted to PHP *want* to code quickly, that’s the whole point.

    They will always take the easiest way out. Look at the use of PEAR_Error in PEAR. Only DB and one other package bothers to extend the PEAR_Error class even though that is the only way to determine the source of an error. Nobody uses error codes to differentiate kinds of errors, except for perhaps 2 or 3 useless codes.

    Exceptions are not inherently inflexible, but I can guarantee that their use (outside of PEAR) will be.

    Greg

  18. While I don’t disagree with you when you say by and large programmers are “lazy.” I don’t think that is a good enough reasons to say exceptions are bad. Exceptions are extremely useful in more complicated, enterprise level code which is the market php was trying to tap with php5. Php4 just didn’t have the features needed to produces maintainable enterprise level code easily.

    So my only point really is that you shouldn’t discount exceptions just because they are misused by people. I would say you might as well avoid them for simpler projects I guess. However, they have their place just like most other constructs. They just take a little bit more time to learn how to use effectively.

Leave a Reply

Your email address will not be published. Required fields are marked *