SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 36 of 36
  1. #26
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by TomTees View Post
    Ha ha. My main use-case including all flows is over 600 lines, so that wouldn't be a good way to help me out.
    Just one click path then. What do people see when they first visit the site? What's your most wanted action off of the home page?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  2. #27
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Chroniclemaster1 View Post
    Exceptions are expensive, so they're generally my 3rd choice.
    Suppose not throwing an exception involves you in writing a boolean if/else check to avoid executing that code and return an error in the function. Suppose also that as the function returns, the callers must check for errors at each stage whether there was an error or not. Let's be generous and assume that the code has an error a third of the time. Now let's suppose that there are four such checks through the call stack. i.e. instead of one throw/catch at the appropriate place, you've had to process 4 boolean checks as it backs out of the function.

    Which code is faster?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  3. #28
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Depending on your language, the main alternative to throwing an exception is silently failing, often resulting in the rest of your code being awash with null checks.

    I prefer exceptions. They are usually more informative and, as Marcus points out, rather than compensating by defensively programming through multiple layers and function calls, it's often better to let the problem bubble up to a part of the program that has the responsibility of dealing with that error.

    For instance, my data access objects don't catch any database errors (can't connect to server, errors thrown from stored procedures, etc.) because how to handle the same type of error is a higher level decision. An INSERT/UPDATE statement that violates a foreign key restraint might be no big deal in some rare cases (just catch the error and move on to the next row) or an UPDATE statement that does not fail but affects 0 rows might be a catastrophic event and require an exception to be thrown manually.

    So, for those reasons and more I prefer to deal with exceptions and catch them generally quite high up.

    Also, I deal with a fair bit of poorly documented 3rd party libraries, and often letting things blow up in your face during testing is the only way to really get to know them.

    Cheers,
    D.

  4. #29
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft View Post
    instead of one throw/catch at the appropriate place, you've had to process 4 boolean checks as it backs out of the function.
    I completely agree. However, I did want to point out other alternatives to going with an Exception as your first choice. I've seen entire books (and all of MS's C# documentation) written with the attitude that throwing an exception IS error handling and that if you do not throw an exception in EVERY function at EVERY level, then you have not included error handling in your program. Both extremes are equally ludicrous. Sometimes error handling is as simple as filling an appropriate default string into a variable for output.

    Quote Originally Posted by disgracian View Post
    Also, I deal with a fair bit of poorly documented 3rd party libraries, and often letting things blow up in your face during testing is the only way to really get to know them.
    Yeah, and people ask me "Isn't it SO much more work to do custom OO programming?" Not when you choose wisely.
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  5. #30
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Also, error handling tends to be so specific that it deals with gross mechanics and I wanted to talk about some general ways to deal with errors. The alternative as we ALL seen in other people's code is lots of....


    PHP Code:
    try {
    ...
    stuff...
    }
    catch {
    ...
    absolutely nothing...

    which I think we can all agree is the antithesis of error handling. It's the *officially* unhandled error.
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  6. #31
    SitePοint Troll disgracian's Avatar
    Join Date
    Aug 2006
    Location
    Samsara
    Posts
    451
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for bringing that up, Chroniclemaster1. That anti-pattern of the empty catch block is one of my biggest peeves. It's the modern equivalent of "ON ERROR RESUME NEXT", and anything that has its roots in VB cannot be a good thing.

    If you're doing that, then it's a pretty big argument for dropping the try/catch block altogether and handling it further up the call stack where some intelligent decision can be made about what to do.

    Cheers,
    D.

  7. #32
    SitePoint Evangelist TomTees's Avatar
    Join Date
    Apr 2010
    Location
    Iowa
    Posts
    553
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft View Post
    Hi...

    Just one click path then. What do people see when they first visit the site? What's your most wanted action off of the home page?

    yours, Marcus
    My design mimics any well developed e-commerce site like Amazon.com.

    You land on the home page, see a search bar, categories off to the side, and featured items in the center.

    Most people will choose a Category, then go to a "gallery" of related Products, then choose to see the "Product Details" for a given Product, then choose to Add to Cart, and so on...

    Why do you ask??


    TomTees

  8. #33
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Chroniclemaster1 View Post
    I completely agree. However, I did want to point out other alternatives to going with an Exception as your first choice.
    Sorry, I was actually asking something very specific. I didn't explain it at all well.

    I think my replacement code for the exception is not unreasonable. If anything it's rather stacked up against the exceptions case. Have you timed it with microtime? That was my request, for you to time it.

    I actually did this (for the first time) before posting the above.

    My code snippet with 33% exception rate ran about twice as slow with non exception code as with exceptions. A bit of poking around clocked a throw and catch as about the same as 4 function calls (about 2 method calls). Sorry, I'm on a different machine right now, so I don't have the code to post, but it's trivial.

    In other words even in this pretty much worse case, exceptions were *faster not slower*.

    When I dropped the exception rate, the code got faster even when I took all but one of the return checks out! A try block with no catch event cost nothing by my measurements, about 10% of a function call was the most I could measure. Far faster than an enclosing if block.

    The statement "exceptions are slow" is a myth, and based on my little experiment, completely and utterly bogus. Avoiding them is almost certainly slowing your code down. It's only the utter irrelevance of such micro benchmarks that have stopped you noticing.

    So let's ignore that.

    The real reason for using exceptions is clean code. A method such as findX() expects a return value that you will use. You just want to go...
    PHP Code:
    $me->sendToYou($my->findX()); 
    Neat, clear and uncluttered. Force your users to spray if/else blocks everywhere and they can say goodbye readability.

    A good API follows the Samurai principle: "Return victorious or don't return at all".

    In other words, don't return a value unless that's the job of the method. Don't return "out of band" error codes and inflict tedious if checks on your fellow developers. They will grow to hate you.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  9. #34
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by TomTees View Post
    Most people will choose a Category, then go to a "gallery" of related Products, then choose to see the "Product Details" for a given Product, then choose to Add to Cart, and so on...
    Ok, so the click path could be:
    1) Home page.
    2) Click "Aeroplanes".
    3) Click "Learjet".
    4) Should see "Passengers: 6".

    I'll do the adding to cart and payment later.

    Quote Originally Posted by TomTees View Post
    Why do you ask??
    public/index.php:
    PHP Code:
    <html>
    <
    a href="category/aeroplanes">Aeroplanes</a>
    </
    html
    public/category/aeroplanes/index.php:
    PHP Code:
    <html>
    <
    a href="../../products/learjet">Learjet</a>
    </
    html
    public/products/learjet/index.php:
    PHP Code:
    <html>
    Passengers6
    </html
    First question:
    1) How do the product listings get on the system?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  10. #35
    SitePoint Guru
    Join Date
    Oct 2006
    Location
    Queensland, Australia
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Some good points have been made throughout this discussion, regarding both object data and relationship handling, and exceptions.

    Just a little tip. If in doubt, go with whatever is simplest. Simple is usually clean, readable, fast and easy to change later if you find the solution wasn't satisfactory. Exceptions as already mentioned, are a simple way to handle... exceptional circumstances (things which shouldn't happen). On the same note, getters and setters are generally speaking, not all that simple, and somewhat violate the constraints of the language (in this case, PHP).

    I've said this more than once so there's no harm in saying it again. Designing a complex heavily-engineered system in respects to either programming or user interface design, is relatively easy. Simplifying that system down as much as possible, requires a much more skillful developer. In the 90's, dialog boxes filled with a 100 options and checkbox's were probably desirable. These days, you have to make decision for your users. No one knows more about the workings of your system than you do, and you should know how it should be used, so make as many decisions for the end user as you possibly can, leaving only the important and most potentially variable decisions up to the user.

  11. #36
    John 8:24 JREAM's Avatar
    Join Date
    Sep 2007
    Location
    Florida
    Posts
    1,508
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've been a little frustrated on this, because I've been trying to keep a uniform system and passing down too many different types of return values from object to object can get tricky to remember down the line.

    I have a public property that can be retrieved from a nested object, ie:
    PHP Code:
    $this->object->Errors;
    $this->object->Output
    However, as mentioned above these could be changed outside of the class is not very good, so thank you for reminding me of a getter setter.

    PHP Code:
    $Errors $this->object->Errors();
    $Output $this->object->Output();

    public function 
    Errors()
    {
      return 
    $this->Errors

    Just tossing in my comments, sorry if it's now irrelevant but this just refreshed my memory and I think that's great advice in this post.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •