On Thu, Jun 4, 2020 at 8:42 PM Michael Jones <michael.jo...@gmail.com>
wrote:
>
> For that to work, it means that a function call either succeeds or fails.
> If it succeeds, then that's that. If it fails, then something special
> happens. Your "#" means "do this only if the function call failed." In that
> case itmust be true that functions have a notion of success and failure,
> that the cause of failure is invisibly returned and available as an extra
> "and here's why it failed" return value, and, new language concepts are
> required to access the value of the invisible return inside that "#{ ... }"
> block.
>
>
There are roughly two ways here:
errors are data flow
errors are control flow
They are, to a certain extent, equivalent since reflection/reification via
monads allows a programmer to convert between these two notions, given the
language has a way to embed monads somewhat easily.
The older I get, the more I want errors to be data flow in most cases. I
don't think there is a good way around that much of programming has the
penchant of failure. It has to be addressed in some way or the other. And
if you have shared memory, there is no way around local handling of errors.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiXJe-YM_kyxoZS-uCvyo%2BGPxtc7p0LtGiirL-FitGL2YA%40mail.gmail.com.
