Then, each time we assign to _!, it assigns that value to err, and checks if err != nil. If the assigned value is not nil, it exits the collect statement, and then the error handling can be done afterward.
...
...
...
congratulations, you just invented try-catch, which is a goto in disguise. truly everything new is old )
when I was inspired by golang (and node I guess)and wanted to do go-like error handling in php, I proposed to add conventional first argument, passed by reference to accumulate errors
after few functions called one can check if any errors occured and then decide what to return from calling function (maybe propagate errors further up the stack)
it was, of course, more of experiment than a complete solution, but it gave an alternative view on exceptions. Exceptions are gotos:
if first function in try block throws, you magically avoid calling second function which is, very likely, acceps value returned by first one as input. So exceptions are making your code obscure and extremely hard to understand. Actually, control on what happens in calling function is now in called function - just throw there and you force client code to obey and go to catch block, even though client code might wanted to do some more calls. Oh you really want to make sure you do that? Welcome to try-with-resources and finally and all sort of even more obscure stuff )
Instead it would be logical to admit that every time you call a function that would otherwise throw, you should really check error returned from this function and then branch your control flow with if statement - this way calling function is back in charge of what is going on. As a result code will look ugly in most of the languages. How to solve this - Im not sure yet, Optionals in java seems to be my next wearpon of choice - most of methods I write are now a chain of Optional.ifPresentOrElse() calls. Pretty declarative, I like to think of myself as a developer who uses functional style, who doesnt?))
Im still in search for THE solution (Im looking at you, monads), but my point here - question everything until you got to the core. Dont run around in circles.
While it's similar to try-catch, collect is a lot more explicit as to what is going on. I'll admit that it's the least favorite of the 3 I showed, though.
When I say it's more explicit, I mean that in a typical try-catch, there's absolutely no indication as to where the error came from. This at least shows which places the error could have came from. Again, it's not my favorite thing in the world, but I'm not entirely against it
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Then, each time we assign to _!, it assigns that value to err, and checks if err != nil. If the assigned value is not nil, it exits the collect statement, and then the error handling can be done afterward.
...
...
...
congratulations, you just invented try-catch, which is a goto in disguise. truly everything new is old )
when I was inspired by golang (and node I guess)and wanted to do go-like error handling in php, I proposed to add conventional first argument, passed by reference to accumulate errors
after few functions called one can check if any errors occured and then decide what to return from calling function (maybe propagate errors further up the stack)
it was, of course, more of experiment than a complete solution, but it gave an alternative view on exceptions. Exceptions are gotos:
if first function in try block throws, you magically avoid calling second function which is, very likely, acceps value returned by first one as input. So exceptions are making your code obscure and extremely hard to understand. Actually, control on what happens in calling function is now in called function - just throw there and you force client code to obey and go to catch block, even though client code might wanted to do some more calls. Oh you really want to make sure you do that? Welcome to try-with-resources and finally and all sort of even more obscure stuff )
Instead it would be logical to admit that every time you call a function that would otherwise throw, you should really check error returned from this function and then branch your control flow with if statement - this way calling function is back in charge of what is going on. As a result code will look ugly in most of the languages. How to solve this - Im not sure yet, Optionals in java seems to be my next wearpon of choice - most of methods I write are now a chain of Optional.ifPresentOrElse() calls. Pretty declarative, I like to think of myself as a developer who uses functional style, who doesnt?))
Im still in search for THE solution (Im looking at you, monads), but my point here - question everything until you got to the core. Dont run around in circles.
While it's similar to try-catch,
collectis a lot more explicit as to what is going on. I'll admit that it's the least favorite of the 3 I showed, though.can you elaborate on how it is more explicit? it is really stopping execution of collected code block and jumps to if err != nil block?
edit:
looks like it is,
Whenever _! is assigned to, an implicit nil check is performed, and if _! is not nil, the block ceases execution.
from original proposal desription
doesnt look differrnt from throw-catch like semantics of other languages
When I say it's more explicit, I mean that in a typical try-catch, there's absolutely no indication as to where the error came from. This at least shows which places the error could have came from. Again, it's not my favorite thing in the world, but I'm not entirely against it