4 ms·

There are some functions for which we know things will break eventually, e.g. a db call. We want to catch those situations, no pun intended. Our options are: re

There are some functions for which we know things will break eventually, e.g. a db call. We want to catch those situations, no pun intended. Our options are: return codes, or exceptions. In the return code case, we're using if/then to handle error situations. In the exception code, we're using try/catch. With respect to spaghetti, they're literally the same thing, just differently indented...

wDcBKgt66V8WDs 8y ago
Meanwhile in the land of PHP I'm convinced that forcing paranoid error levels and converting all errors to exceptions is the only safe way to develop. Too many times in PHP the return type of a function is not what was expected from documentation and I'm not about to do type checking in addition to value checking every function result. Ridiculous. So type-aware comparisons and errors to exceptions it is. Whatever code called a file that managed to hit a bad return type can now continue living and logging instead of `PHP Fatal error` edit: or the PHP special of hitting an error down the stack and again just dying without passing the message up the chain. That is no way to work.
- victorstanciu 8y ago
  > forcing paranoid error levels and converting all errors to exceptions is the only safe way to develop Oh, absolutely. That's how I do it too. Unfortunately, warnings and notices are still a thing in PHP 7. So the best practice is to just install an error handler that turns these into exceptions. They they are either handled by code, or by a catch-all handler. This is in fact what I've implemented SlashTrace to do by default: https://github.com/slashtrace/slashtrace/blob/master/src/ErrorHandler.php#L38 https://github.com/slashtrace/slashtrace/blob/master/src/Err...
krispbyte 8y ago
The alternative is the Result or Maybe objects with pattern matching from functional languages. It seems similar to return codes with if/then, but the strong typing and the match forcing you to deal with all possible branches (or pass it along) makes it less spaghetti looking.

wDcBKgt66V8WDs 8y ago

Meanwhile in the land of PHP I'm convinced that forcing paranoid error levels and converting all errors to exceptions is the only safe way to develop. Too many times in PHP the return type of a function is not what was expected from documentation and I'm not about to do type checking in addition to value checking every function result. Ridiculous. So type-aware comparisons and errors to exceptions it is. Whatever code called a file that managed to hit a bad return type can now continue living and logging instead of `PHP Fatal error` edit: or the PHP special of hitting an error down the stack and again just dying without passing the message up the chain. That is no way to work.

victorstanciu 8y ago
> forcing paranoid error levels and converting all errors to exceptions is the only safe way to develop Oh, absolutely. That's how I do it too. Unfortunately, warnings and notices are still a thing in PHP 7. So the best practice is to just install an error handler that turns these into exceptions. They they are either handled by code, or by a catch-all handler. This is in fact what I've implemented SlashTrace to do by default: https://github.com/slashtrace/slashtrace/blob/master/src/ErrorHandler.php#L38 https://github.com/slashtrace/slashtrace/blob/master/src/Err...

krispbyte 8y ago

The alternative is the Result or Maybe objects with pattern matching from functional languages. It seems similar to return codes with if/then, but the strong typing and the match forcing you to deal with all possible branches (or pass it along) makes it less spaghetti looking.