3 ms·

Disagree. We could argue what counts as "exceptions", the jargon goes places (e.g. CPU exceptions are nothing to do with "exception handling" for example.) I'd

• 9rx 1y ago
  > We could argue what counts as "exceptions" What is there to debate? An exception, by every definition I have ever encountered, is a data structure that contains runtime information (e.g. a stack trace) to stand in for a compiler error where the compiler was not sufficiently capable of determining the fault at compile time. It couldn't possibly mean anything else in reason. Of course, we're really talking about "exception handlers", not "exceptions". > there's no try, no catch, and no throw, and no equivalent to any of those. There can be in name and reasonable equivalency: https://go.dev/play/p/RrO1OrzIPNe https://go.dev/play/p/RrO1OrzIPNe I'm not sure what it buys you, though. You haven't functionally changed anything. For this reason, I'm not convinced by the signifaince of syntax. Think about it. Go could easily provide syntax sugar that replaces `try { throw() } catch (err) {}` with `try(func() { throw() }).catch(func(err) {})`. That would truly satisfy your requirements in every way. But what, specially, in that simple search and replace operation says "exceptions" (meaning exception handlers)? > C also has setjmp/longjmp which can be used in similar ways, but I wouldn't call that exception handling either. Agreed. You could conceivably craft your own exceptions to carry through the use of setjmp/longjmp, but that wouldn't be a language feature. However, Go does have an exception structure as a built-in.
  • jchw 1y ago
    The Wikipedia article about Exception handling[1] does a better job discussing the history and background IMO. Also, obviously when we say "exceptions" in a programming language, we're definitely talking about "exception handling", the word is omitted because it's obvious on context. I'd argue that one's on you if you thought otherwise. (If we're just talking about an "exception", well the Go error object is an "exception", but it's pretty obvious you're not merely talking about that.) True to my word, I won't argue over the definition itself. [1]: https://en.wikipedia.org/wiki/Exception_handling_(programming) https://en.wikipedia.org/wiki/Exception_handling_(programmin... P.S.: > There can be in name and reasonable equivalency: https://go.dev/play/p/RrO1OrzIPNe https://go.dev/play/p/RrO1OrzIPNe I'm not sure what it buys you, though. You haven't functionally changed anything. For this reason, I'm not convinced by the signifaince of syntax. To me this is no different than implementing "exception handling" with setjmp/longjmp, just less work to do. For example, Go doesn't have pattern matching; implementing an equivalent feature with closures does not make this any less true.
    • 9rx 1y ago
      > The Wikipedia article about Exception handling[1] What's that old adage? I think it goes something like "The wiki is always accurate—except when it’s about something you know personally." If you don't enough about the topic to discuss it yourself, what are you doing here? > Also, obviously when we say "exceptions" in a programming language, we're definitely talking about "exception handling" Not necessarily. Often it is important to discuss the data structure and not the control flow. Strictly, "exception" refers to either the broad concept of exceptional circumstances (i.e. programmer error) or the data structure to represent it. "Exception" being short for "exception handling" where context is clear is fine, but be sure context is clear if you want to go down that road – unless you like confusing others, I suppose. > well the Go error object is an "exception" You mean the error interface? That's not an exception. It's just a plain old interface; literally `type error interface { Error() string }`. In fact, the only reason it gained special keyword status is because it being part of the standard library, where it was originally defined in early versions, caused cyclical import headaches. If Go supported circular imports, it would be a standard library definition instead of a keyword today. The underlying data structure produced when calling panic is an exception, though. It carries the typical payload you'd expect in an exception, like the stack trace. Of course, errors and exceptions are conceptually very different. Errors are for things that happen in the environment – invalid input, network down, hard drive crash, etc. Exceptions are for programmer mistakes – faults that could have theoretically been detected at compile time if you had a sufficiently advanced compiler. Obviously you can overload exceptions to carry unexceptional information (as you can overload errors to carry exceptional information), and a pragmatist will from time to time, but that's not the intent for such a feature[1]. > To me this is no different than implementing "exception handling" with setjmp/longjmp, just less work to do. Aside from the fact that there is actually an exception involved. Again, while you might be able to hand roll your own exception data structure in C, it does not provide it for you like Go does. If setjmp/longjmp were paired with an exception data structure of the box, it would reasonably considered exceptions, naturally. However, the second bit was the real meat of that. A tiny bit of search and replace and you have a system that is effectively indistinguishable from exception handling in languages like Java, Javascript, etc. You haven't explained what about that search and replace, that does not introduce any other new language features or introduce any new concepts, turns what is not exceptions into exceptions. [1] Java and its offspring's failed experiments in seeing if errors and exceptions could reasonably be considered the same thing excepted.