
On Thu, Feb 21, 2019 at 11:32 PM Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Feb 22, 2019 at 2:27 PM Juancarlo Añez <apalala@gmail.com> wrote:
Then, if exceptions are going to be part of a type, there should be a way to express the semantics of them (like in Eiffel), so stack.pop();stack.push(x) doesn't have to catch StackFullException.
That assumes atomicity. If you want an atomic "replace top of stack" that can never raise StackFullException, it's probably best to express it as stack.replacetop(x) rather than having something that might be interrupted.
Ah! What to do with an exception in a concurrent context? Abort, or retry after a while?
People do dumb things with exceptions, yes. Why does this mean that they are bad? I don't understand this. Exception handling (and stack unwinding) gives an easy and clear way to refactor code without having to daisychain error handling everywhere. How is throwing that away going to help people write better code?
For programs that are recursive or multi-layered, exceptions are a clean and efficient way to unwind. This PEG parser generator I wrote was made possible because Python exceptions are semantically clean and very efficient: https://github.com/neogeny/TatSu/blob/master/tatsu/contexts.py
But then, Golang also decided that Unicode wasn't necessary, and we should all deal with UTF-8 encoded byte sequences instead of text strings, so I'm fairly sure there are no ten foot barge poles long enough for me to touch it with. There are languages that have problems because of history (*cough*JavaScript*cough*), but for a new language to make multiple poor decisions just means it's one to avoid.
The quest for a programming language in which _"anyone"_ can program, _without_ making mistakes, has never ended, and probably never will. "Alexa! Please write the software for a new Internet email system that overcomes the limitations of the current one!" Sometimes staying away is not an option. -- Juancarlo *Añez*