Re: Common way of error handling?

Stig Bakken wrote: > > Ulf Wendel wrote: > > > > This works fine as long as you don't have functions that return negative > > integer values. By the way I don't like the idea that return types > > suddenly change. > > PHP has lots of functions with "mixed" return types. I like your > suggestion, but I think the created error objects should be returned. > That is the only way the user can catch and handle the errors. Yes, I know about this point. I decided to do something like this: class foo { function bar() { $this->err = new exception_io("Can't read file 'bar'", 1, __FILE__, __LINE__); } } ... on course this doesn't work with static classes. > > How does PHP itself handle this situations? PHP sometimes stops > > execution, sometimes returns false and sometimes return 0 or "" or an > > empty array. It always displays an error message unless you supress it. > > I think we can't do better but simulate this behaviour. > > IMHO, stopping execution and displaying an error is a very clumsy way of > handling errors, we should try doing better. The best thing would be to > have real exceptions, the second-best is to return error objects. Can you place real exceptions on the PHP4.1 wishlist? During the developement of an application that uses certain modules/classes it can be helpful to stop execution whenever an error occurs. I would like to be able to configure a "halt on error" for debugging purpose. > > We would get: > > - five basic exception (notice, warning, error, io, runtime) > > What is really the distinction between a runtime error and others when > the script is running? :-) Think of a module, that parses some files. Calling a method getFiles($files) where $files="" or calling get() before before using setFiles($files) to define some files yould cause a runtime error. Runtime errors are thrown if the API is used incorrect. > My main problem with your exceptions is that they act like signals, but > without returning control to the interrupted function. I want to be > able to write code that is something like this: > > $res = $dbh->query("INSERT INTO names VALUES(?,?)", > array($id,$name)); > if (PEAR:isError($res)) { > if ($res->errorCode == DB_ERROR_CONSTRAINT) { > print "$name ($id) is already in the database"; > } else { > log_error(3, $res->errorMessage()); > print "some error occurred, please talk to the > administrator"; > } > } > > I have a problem with defining error handling functions, since they give > the user less graceful degradation when an exception occurs. But we can > have a compromise: the user should be able to configure whether he wants > to have "in-lined" error handling like in this example, calling an error > handling function (or object+method), or to print the error and > optionally stopping execution. Yes, I got it. Our attempts are not that different. My exceptions do have handlers that are called by default. This could be made configurable as well as the default reaction on an exception is configurable. Then it's up to the user how to deal with errors. I still don't like the idea of lots of defines, a function isError() in every module and mixed return types, but I have to agree that there is no real alternative. I personally preferr an instance var $err containing the error object, but that does not work with static classes. Your latest suggest seems to be the best way. How about the different types of exception I was talking about? Do we follow Java and have lots of predefined exceptions. I would like to have more than five. That makes error handling easier. The user doesn't have to learn all predefined errors that a module could "throw", he gets informations of the "kind" of the exception and we reduce the number of defines. I could think of the following exceptions: - notice - warning - error - io: "Can't connect source", "Invalid login", "Can't read file", "Directory not existant", "Can't create file", "Error while talking to source", .. - runtime: "wrong params - illegal function call", "wrong API use", ... Ulf