On Wed, Jun 2, 2010 at 12:49 AM, Chad Fulton <chadful...@gmail.com> wrote:
> Hello! > > > As I mentioned, I think that we have to inform the caller about the > problem > > (be either a type or a conversion mismatch), so the only options to > trigger > > an error, or throw an exception. > > I like the exception idea better, because it can be easily handled localy > > (no need to register a global error handler), but as the core devs said, > it > > isn't allowed to throw exceptions from the core, so this is why I think, > > that the weak type hinting should be implemented as an spl interface. > > This way we could even support array - ArrayObject conversion too. > > > > http://wiki.php.net/rfc/splweaktypehintingwithautoboxing > > I'm not sure what is being added by using the SPL interface except a > way to justify throwing exceptions on type mismatch with data loss? > > The only reason I can think of for throwing exceptions in this case > would be data validation purposes, which I think is not the intention > of type hinting, and also not the intention of exceptions (users > inputting bad data is not an *exceptional* occurrence imo). > > Is there some other reason / use case for wanting exceptions? So, I > mean, where is the use case where '123abc' will be passed to a > type-hinted field where you could catch the exception and do something > meaningful to carry on with the execution of the program other than > simply error-ing out? > I think I *did* mentioned, why I prefer exceptions over errors. The first thing is, that you han handle the exception in the original scope, so you have all the avaiable data to carry out your decision about the error. Maybe you want to log that faulty record, then continue the batch processing, which was just interrupted. With trigger_error, the error handling happens in a new empty scope plus it's not a trivial task to do the cleanup(flag the mismatching record in the db to human review) and resuming the original batch operation. Plus, usually, if you are using objects, and spl interfaces (which has its own set of default exceptions) there is a high chance, that you will use exceptions, to handle the errors, so it comes natural to me, that we don't need a mixed set of error handling methods. Tyrael
