Thanks for suggestion about assert() use cases, i know it exists before, but never used.
Usually if something shouldn't happen i throw exception there, or at least type control. Its like manual mark for the future - you doing something wrong, fix it. Error collection case its about "you're right, but external system doesnt think so". Example 1: i send correctly and valid first name (for my system) to external system. That system reported thats name contains character outside its regular expression. I can solve it in-place creating function with regular expression that change invalid chars to question marks and case will be covered. Example 2: My system result is less than zero. Remote system expects greater than zero. I cant just validate/sanitize data to greater than zero. If i send single operation - it could be the exception. But there could be two cases - multiple operations (commands) queue or bulk operation (one command, few rows of different data). In first case i have to stop all operation, exception could help me. In second case same error becomes to warning, and one row should not stop whole process, but have to report me. So previously i solved it with exception, and now exception shots my legs. Thats why i use exceptions only if something wrong on developer/user side, and never to system-system cases. if() still powerful. ср, 7 февр. 2024 г. в 03:55, Alex Wells <autau...@gmail.com>: > On Tue, Feb 6, 2024 at 7:14 PM Larry Garfield <la...@garfieldtech.com> > wrote: > > > These two samples *are logically identical*, and even have mostly the > same > > performance characteristics, and both expose useful data to static > > analyzers. They're just spelled differently. The advantage of the > second > > is that it could be implemented without generics. (ADTs would be an > > optional nice-to-have.) And if the caller doesn't handle DivByZero, it > > would try to pass it up to its caller, but being checked it would require > > the caller to also declare that it can raise DivByZero. > > > > Let's assume that the developer knows the divisor isn't 0 - through an > assertion or an `if` clause above the call to `divide(5, $divisor)`. In > this case, DivByZero error cannot ever be thrown (or risen), but the > developer would still have to either handle the error (which will never > happen) or declare it as raisable, which in turn may require also marking > 10+ function/method calls as "raises DivByZero". Both options aren't great. > > And even if there was no assertion about the divisor, maybe the developer's > intent is exactly to ignore that case as an "implicit assertion" - meaning > instead of explicitly asserting the divisor value themselves (through > `assert($divisor !== 0)`), they rely on `divide(5, $divisor)` doing that > implicitly for them. If the `assert()` fails, then nobody is expected to > really handle that assertion error; it usually bubbles up to the global > exception handler which takes care of it. If the `divide()` fails on the > other hand, checked exceptions would require all the callers to actually > "check" it by catching or declaring the caller function as `raises > DivByZero`, but this doesn't bring any benefit to the developer in this > case. > > So I assume this is why Java developers hate checked exceptions and why > Kotlin doesn't have them. I'm not aware of other implementations of checked > exceptions; there may be other, better versions of them. If you have any in > mind that overcome the issues above, I'd be interested to look into them :) > -- +375 (29) 676-48-68 <+375296764868> / Mobile - предпочитаемый способ связи https://t.me/gzhegow / https://t.me/%2B375296764868 / Telegram 6562...@gmail.com
