Thanks Larry, I will read both articles next weekend. Am not even talking about changing `throw` to `raise`.
Am talking only about: - production ready code - that should be able to refactor with error collectors (that was not implemented years ago) - without touching return types - without touching input arguments of existing code - without possible code fall after throw exception: you have to try/catch all places you use that function (sometimes you predict possible error, and yes, write return class/enum to extend/refactor it later) (and yes, if old code did not support returning null/null-object before - you have to refactor return types then) While working with queues you have a list of tasks - then you reduce it to smaller with reducer (unique/filter/merge) - then do some queries - then walk initial data using reduced results: copying reports to save errors/warnings to each task separately It cannot be solved with exceptions. In addition, large arrays throw exceptions that cause timeloss. It's definitely not a tool for. Also your method could return many errors (today - only one error/exception), and you need to write a second method, then call the second method, then debug the second method. So what's in rest? Arrays collection of warnings and errors. Changing return types or passing second-return by reference. [ Enum case ~ DTO output ] covers newly written code. Old code is uncovered. You have to rewrite a full tree, that's why some trick is necessary. I did it my way with an error bag stack. I enable it inside the function or in place I call the function. I want to share this experience, and imagined it would be better for all users. It could be done without 2 classes, 10 functions and work with push/pop/current (closer to ob_start/ob_get_clean story). I guess it could be implemented if `raise` world will put any data to the current error bag in the stack. Exactly if the current error bag is present (declared manually like you can declare() strict types or ticks for some scope). I agree that there's more mandatory problems to solve that I didn't even know about. I tried to talk about error handling with a few developers, all of them recommend: 1. Use exceptions, don't make anything fresh 2. Do validation at the script start to reduce the count of errors later I've just encountered cases where bugs come from within - once you integrate a really bad external system with its own checks, which are described in hundreds of documents, I'm sure you'll encounter new bugs once the "working" code is released to production. And then you will need to quickly and easily reorganize it. And you can't. And you will be sad. And, "PHP moves differently" is a completely wrong principle, I believe in "watching for". -- +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram 6562...@gmail.com
