> > > I'm aware there are cases where @ still has to be used. What I meant was > that PHP should let you write clean code that doesn't require error > suppression, or require you to jump through hoops to avoid errors. I look > forward to the day when that might be possible. > > David > > > there will always be situations when an operation cannot be completed and it has to be reported somehow. currently a function can report the error multiple ways: - it can return false like mysql_query, and you can fetch the error with a different method. - it can return NULL, like json_decode (be aware that the NULL return can also mean success :/), and you can fetch the error with a different method. - it can return false and trigger an error/warning/notice like iconv. - it can throw an exception, like for example Spl and the Reflection stuff does. - it can do some of the above depending on some configuration option, this is what PDO::ERRMODE_* does for example.
and what I forget to mention. :) and it sucks that currently you cannot do some things without making errors which are expensive, wether you collect the errors or not. :/ so I think that some reboot/refactor about the error/exception handling would be a really good thing, of course we can do such changes only in major or maybe with minor version bump. another thing would be to make the error/exception handlers to be truly stackable (so there would be possible to have more than one active handler, be them distinct or overlapping) and have the ability to set the class/interface when you set_exception_handler, just like you set it for catch statements. ps: that post went longer and more off-topic than I expected, maybe an it would be better as an RFC... Tyrael
