Simple error checking in PHP class function chaining?

I've found some limited use in chaining class functions, say $class->setUse开发者_如何学运维r('foo')->getInfo() (bad example) although am having trouble understanding how to handle any errors that arise from one of the calls in the chain.

If setUser() for example came with an error, and returned false, it would not return $this and not allow another function to be called, thus displaying an error.

What I have actually just realized (and correct me if this is wrong), would throwing an exception if there is an error in setUser() prevent the following getInfo() function from running and emitting an error?

This would be useful knowledge to at least have, so that I can debug code that uses chaining even if I am not to use it.

Yes, throwing exceptions would probably be a good idea in this case. You'll be able to pinpoint where the error happened in the chain.

Here's an example of how that could work:

try
{
    $class->setUser('foo')->getInfo();
}
catch(UnknownUser $ex)
{
    // setUser failed
}
catch(CannotFetchInfo $ex)
{
    // getInfo failed
}

As with any chains: If one element get's broken, the whole chain get's broken.

So if you're chaining objects, on the one hand this might be very accessible, on the other hand if things tend to fail due to errors (e.g. remote connections, files etc.), chaining becomes awkward.

So unless things do not return the expected type of response but signal a failure, exceptions can help but are - as the chain get's broken - of limited use.

However, I think that throwing exceptions is the best thing you can do for error handling (in chains and for developing own code).

The benefit of throwing an Exception is the following: You don't need to destroy the syntax that makes the chain accessible.

Let's say you have made an error in your code. It's better to throw an Exception as you need to fix it anyway.

Or let's say the data layer has been coded that it fails too often. Throw an exception, then you know about the part that needs more love.

In your general-use code, that has the chaining, these exceptions will interrupt you (you can always catch them, and btw you can turn errors into exceptions as well), but they will point you to a cause of error you might have not thought already enough much about.

So,

1. Exceptions are a way of error handling for chains
2. Exceptions help you to locate various sources of errors while you can maintain the chain syntax for a higher level of data access.

Regardless how well chaining is done however, there comes the point where it does not make sense any longer (should I add "as with everything" ;) ). I wouldn't say I'm a real fanboy of chaining, but even as a non-fanboy I use the principle from time to time in my own code. It can create easy to write code, so make use of exceptions for the error handling, I didn't run into any "real" (tm) problems with it. It's much better than breaking your chain with a false or some crap like that.

Theoretically you can return an object that takes any property/member call set/get via overloading, but even if this is fun to play with, I think it will only introduce more complexity than it helps to deal with actual, real life errors.

So if you chain into an error, you actually see the error when you use an exception. That's what exceptions have been made for: Interrupt the standard processing of your application because of an error (or signal, works as well).