Re: Error handling brainstorming

Levi et al: On Mon, Aug 6, 2012 at 8:55 PM, Levi Morrison <morrison.levi@gmail.com>wrote: > >> Because checking that the returned variable is !== > >> FALSE is *way* > >> better than throwing an exception, right? > > > > Yes, it is. You can control it, unlike the exception which you can not, > > unless, again, you wrap everything into try/catch on every kind of > > exception possible. > > > >> This type of thing is one of the main reasons I like PDO more than > >> MySQLi. In MySQLi I'm constantly checking return values. In PDO I > >> just wrap it all up one try/catch. It's not like if my query fails > >> I'm going to try a different one. Most of the time it's just logging > >> that something went wrong and reporting it upstream somehow. > > > > You are using exceptions for normal flow control. It is not what > > exceptions should be used for. They are called exceptions for a reason. > > > > > It *should* be an exceptional situation if my database queries don't > work properly. I've tested my code locally, on a staging environment > and sometimes even ran tests on the live server. It is absolutely > 100% an exception if something goes wrong, my friend. > > Opening a file? I have to agree that it should not throw an exception. > I was replying more to explain the benefit of exceptions than to > refute that one possible use-case. It should absolutely throw an exception. If you're opening a file, and the file doesn't exist (in read mode), that's definitely an exceptional circumstance. If it's not, you should be checking for existence first (via file_exists() or is_readable(), etc)... The only situations I consider non-exceptional in terms of PHP errors are those that don't alter the flow via error return. So if fopen errors, you can't just fread the return value. You *need* to change your execution flow based on that error. Therefore, it is exceptional. However, cases where you can logically continue on would not be exceptional. Cases such as substr($string, 100) on a 2 character string, currently raise a warning, but getting an empty string back from it allows you to continue on. The rest of your code won't be effected by the error in a significant way (since the case where the string is 2 characters is the same as if it's 100 characters). So, as a gross overgeneralization, Can I continue on without **having** to check the return value? Yes: Not an exceptional circumstance No: An exceptional circumstance Again, as a gross overgeneralization. Not as a hard rule, but as a quick check... Anthony