Hacker News Reader

Comment by tiniuclx | Hacker News Reader

An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding a new concept to the language (e.g. C++ exceptions) can systematically make these changes unnecessary, therefore simplifying the program.

Perhaps this is how programming language designers ought to vet language ideas: do the proposed changes make certain patterns redundant? Looking at Rust through this lens makes it clear that it aims to eliminate C-style manual memory management.

However, it does make me wonder: How do languages such as JavaScript and Python stand out from their predecessors, and what problems do they uniquely solve?

View on HN

The wikipedia summary of the JavaScript design rational is decent; it also kind of explains why it's so odd:

> In 1995, Netscape Communications recruited Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator.[11] Before he could get started, Netscape Communications collaborated with Sun Microsystems to include in Netscape Navigator Sun's more static programming language Java, in order to compete with Microsoft for user adoption of Web technologies and platforms.[12] Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax, which excluded adopting other languages such as Perl, Python, TCL, or Scheme. To defend the idea of JavaScript against competing proposals, the company needed a prototype. Eich wrote one in 10 days, in May 1995.

It had to look vaguely like Java (hence ALGOL-derived brace delimited blocks rather than Scheme-derived prefix S-expressions, and the confusing name), and it had to be implemented quickly (hence the lack of typechecker and other advanced features), and it was intended to be beginner-friendly (hence all the truthiness/falsiness stuff).

Javascript only succeeds because it's the only scripting language supported by web browsers, and the brief attempt at getting VBScript into browsers was even worse.

> and it had to be implemented quickly (hence the lack of typechecker and other advanced features)

Since then there has been more than enough time to implement optional static types.

In fact, the EcmaScript 4 proposal had those, before it was trashed in 2007 or so and the TC39 started EcmaScript 5 from scratch.

JavaScript is fine for the job of hooking light-duty events to HTML, but people try to write entire GUI/graphics engines in it. It's the wrong tool for that job, just as you don't write an OS in TCL. The whole Web UI "standards" issue needs a big overhaul in my opinion, but Web UI's is probably off topic. (I've ranted about it in other topics.)

This seems like an extreme case of “assume your hack will be used in production for years to come.”

> exceptions > simplifying

Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding...

A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests.

An even better (but orthogonal) way is to structure the code so it does only one thing at a time, and does any one thing only in one place (ideally).

compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.

Look up the definition of "simple".

How exactly do you distinguish "exceptional" from "non-exceptional"?

> Look up the definition of "simple".

There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise.

I would say exceptional is a situation that is rare and unexpected. When saving a record to a table with a unique constraint, I would expect the constraint to prevent saving but I would not usually attempt to handle/recover the app running out of memory.

So it's situational and I'd say the distinction is between whether you will be explicitly handling the event as part of normal behaviour. The more stable the app needs to be, the more situations need to be handled.

I agree and I think the conclusion is that it's up to the caller to decide what is exceptional. But unfortunately it's the callee who decides how the result is returned.

And it's not only the caller, but also the caller of the caller, and so on, who needs to be prepared for exceptions. This all has severe ramifications on the code structure.

> There's no need to be dismissive. I refer to simple as simple to use, not simple to conceptualise.

Sorry. I need to control myself. It's not about you. As another commenter stated there is an agreed upon distinction between simple and easy. The distinction is important especially among programmers, and what you described might be easy but it's not simple.

agreed, there are better ways to handle such circumstances (such as an Either/Validation monad). But I still think exceptions are better than error codes. If you don't handle an error code, you can proceed through your application in an invalid state. If you don't handle an exception, the application crashes out. I think the latter is preferable in most circumstances.

Yes, and this is the reason why I'm happy with exceptions for short scripts, e.g. Python. It's a different story for larger projects where I make all the primitives by myself. There I start by explicitly aborting on cases that are not handled yet (no exceptions needed to do that), and then I gradually change the structure of the code to handle more and more "exceptional" cases.

I suspect you're the exceptional case though (ha ha) because error codes don't cater to inexperienced developers as well as exceptions do. They are much more liable to cause your application to fail silently unless you explicitly prevent it, as you do. Good tools are all about enabling average or inexperienced developers to not fall into those pitfalls so from that perspective, exceptions are better. Usually those tools aren't very nuanced so they can get in the way of experienced or skilled developers and you end up battling the framework instead of getting productive work done. That sucks, but it's a trade-off most companies (consciously or unconsciously) accept.

You're not being dismissed. You're being corrected.

The GP, along with many other people, are trying to get software professionals to standardize on a definition of simple that means something like "composed of a single element; not compound" or "easy to reason about".

Under such a standard, it makes no sense to talk about "simple to use" vs "simple to understand". You can talk about "easy to use" vs "easy to understand". The latter might mean "simple". But "simple" never means the former. And you never say it's "simple to X" for any value of X.

Under such a standard. The degree to which people are converging on this standard in actuality is not clear to me.

no-one told me about this standard when I entered the industry. If it comes from some blog post that I haven't read, how am I meant to know that some small selection of developers prefer "simple/easy" as a dichotomy? It's not a correction if it's just a different opinion.

There is a very popular talk by Rich Hickey (creator of Clojure), "Simple vs easy". Maybe that was what popularized the distinction among many programmers.

It's really not an arbitrary definition if you think about it etymologically. Very freely sim-ple is "unfolded" (c.f. pliers, plier qc). Whereas com-plex is "folded together". "Easy" relates more to a state of ignorance. It's about the user of the thing, not about the thing itself. (NB I'm just making this up. I'm not a linguist so I might be wrong).

it makes sense as a distinction and I'll likely use it going forwards. The only thing I objected to was the idea that this distinction is something I should already know as a programmer. I guess it comes down to a case of separate bubbles/backgrounds, as I've never heard the distinction before in my time in industry and I'd guess it's considered standard jargon within your environment?

I would assume most HN folks have heard of Rich Hickey and his talks. Surely not all of them have. Learning never ends :-)

I knew about him, but haven't seen / heard of his talks.

The best description of exceptions that I've seen is Bertrand Meyer's exposition of them in _Object Oriented Software Construction_.

His definition depends on the notion of Design by Contract. An exception is an event that causes a function/method to fail because it is unable to satisfy its contract. The caller is then responsible for cleaning things up (so it can satisfy its contract) or it also triggers an exception resulting it its failure.

In the context of Design by Contract, the list of things that can cause an exception include:

  * hardware/OS errors
  * calling a method on a null reference
  * calling a method that itself fails
  * discovering a pre-condition isn't true
  * discovering that a post-condition isn't true
  * discovering that a class-invariant isn't true
  * loop invariant failure or lack of progress
  * assertion failures
  * explicit triggering of an exception

I highly recommend Object Oriented Software Construction.

I think this is a hair-splitting distinction and it does not work reliably. Sorry. Things that truly "cannot" happen => you do not know how to recover => you terminate the program. That's it.

That is why the definition is recursive. If every failure triggers a new exception all the way up the call stack, then your program fails.

Yeah, so what was the point to begin with?

Do you understand Design By Contract? That is the theory that provides the distinction between a function/method finishing with success or with failure. The notion of contract is what distinguishes an exception from a glorified GOTO.

In re-reading, my response comes across as much more flippant than I intended. I was just trying to re-emphasize that the definition of an exception is an integral component of Meyer's design by contract methodology and not a stand alone concept.

I've written an article on error handling some point and ended up with: "An error is when the program is operating outside the intended path of execution."

What counts as intended is a question of definition, but in concrete examples of local reasoning within a function this question is usually easier to answer. Thinking about it in terms of (explicit or implicit) contracts, like Bertrand Meyer, sounds like a smart idea.

https://blog.gnoack.org/post/error_handling/

> Warning: Textual logging is not an error handling strategy. Logs are not meant for machine consumption so it’s hard to have automated monitoring based on them.

I'd beg to disagree.

As for the general statement of your post, I like how you're talking about stakeholders and (specification) bounds but I don't think it's an actionable viewpoint. The idea of "Bubbling up errors" inside a program is caught in the software reuse mindset but it's not possible to take action on encountering a true error (here "true" means "outside specifiation"). That's because the state of your whole program is undefined after the encounter. Which means that the best you can do is to call abort() and hope that the program will end with some info for debugging.

(Unless we are talking about a VM or sandboxed code, in which case again you could just call some equivalent of abort() from the code inside and "catch" that in the host code and restart the VM or something).

In Java, your true error dichotomy is done using checked versus unchecked exceptions. Checked exceptions can usually be handled while unchecked exceptions usually can’t be, so they aren’t usually caught and instead just bubble all the way up.

Thanks for the feedback. :)

To clarify, in the context of the article, "making errors observable from the outside" is not meant at the per-function level, but meant at the level of the whole program, which includes abort(). I should improve the wording there.

abort() is perfectly legitimate if you can't recover within the same process. It's not at odds with routing to the right stakeholder, as long as the parent process catches the crash and does appropriate error handling (e.g. "Send a crash report" dialogs or other watchdogs).

Regarding textual logging, I'm not sure exactly which part you disagree with. :) I'm aware that people commonly write regex-based extractors, and I've done the same, but having the choice I'd always go for a more schema-ful error reporting channel. That's more lightweight both for reading and for writing it, and avoids a whole class of regex bugs.

OK I had probably skimmed too much but now I think we're just talking about different things here. I like your post, so let's give it another chance: https://news.ycombinator.com/item?id=18390030 :-)

Regarding textual logging, I think it works wonderfully and I don't think it's at odds with schema-ful reporting. One good way is to include error codes. Informal messages are at least as important. They are ergonomic to humans and their meanings are easy to look up with a web search.

Of course textual logging can always be supported by other means, like crash dumps.

>I highly recommend Object Oriented Software Construction.

I do, too. I had read most of the book [1] some years ago. It is really good. But readers should know that they need to be ready to put in enough time to read, understand and digest it, not just because it is a thick book, although it is that, but because, true to Bertrand Meyer's style, it is detailed, systematic, thorough, etc. It's not one of those books where you can read it in a few days and then start applying its stuff to your work, nor is it for casual programmers who are only into the field to make some quick bucks.

[1] https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...

BTW, the book may have an Easter egg in it.

Don't mix up simple and easy, they are orthogonal concepts.

Exceptions are in no way simpler than C-style error codes, but in many cases they might be easier to work with.

simple to use versus simple to understand. I was referring to the former.

Case in point: Python’s StopIteration exception, which is raised to indicate iterator exhaustion. A lot of efficiency can be gained by not invoking Python’s heavy exception handling machinery for this.

You do have a point, adding exceptions to C++ does impact the language in many ways. They must be used responsibly: being able to jump to a completely different point of the program at any time is dangerous.

However, exceptions do simplify some situations, such as when an unrecoverable error happens at the bottom of a deep call stack. Exceptions make it simple to inform the user/system that an error has occurred without adding error checks to every function in the call stack. I believe this use-case justifies the feature, especially if you can tolerate the performance loss which might not even be that bad [0].

Having the compiler check error codes is one of the reasons I enjoy Haskell so much: the type system makes you handle failure (amongst other things).

[0] http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf - Section 5.4.1.2 - the table approach to exception handling has no run-time cost during normal (non-exceptional) program flow.

The efficiency problem need not be the exception handling in itself (I can't say a lot about that. There are various claims and it probably depends on the tradeoffs of the language implementation).

The actual problem is the ramifications on the code structure. A deep call stack with a lot of implicit context is a problem in itself. Exceptions imply a temporal coupling from error occurrence to error handling. This is a subtle but severe problem. It might start out as a noticeable maintainability problem but it's likely to quickly become a performance problem as well...

> Exceptions imply a temporal coupling from error occurrence to error handling.

Could you expand on this? I understood your statement as "Exceptions sort-of force you to handle an error the moment it occurs", but I'm having trouble seeing why this would be specific to exceptions and not the case with other error handling solutions.

(I don't mean to sound like a big exception-defender – I prefer ML/Rust-style Result types)

A rather odd example with Result type systems: Say you have a function that returns the results of three other functions together in a tuple and the first one errors. The other two can still run and their result can be returned in the tuple along with an Error for the first function.

Ah, so using Result types you can return

  `(Optional<A>, Optional<B>, Optional<C>)`

– each can fail or succeed independently. But you can't do that if you're using exceptions to signal errors – it's like returning

  `Optional<(A, B, C)>`

, you get either all the results or nothing. Good example, thanks!

You can still get something like that using exceptions, it depends on where the exceptions are caught. If you have a function which has 3 calls:

  function f (...) {
    val a = something.a();
    val b = something.b();
    val c = something.c();
    return (a,b,c);
  }

If the exceptions can occur in the calls assigning to a, b, or c and are handled locally (here, in f) then you can construct that first case. It's only if you throw the exception up one level higher that you end up in the latter case. As written, it is more like your latter example. But with a modication:

  function f(...) {
    val a = default_a;
    val b = default_b;
    val c = default_c;
    try {
      a = something.a();
    } catch {
      a = error_value_a;
    }
    ...
  }

You can get the former case.

In some cases immediate action might have to be taken (like calling abort()) but very often that is not the case. Another strategy is to collect errors. Then decide what to do them at another point (no temporal or physical coupling!). After all errors are collected, you can group them, sort them, or aggregate them. Whatever is appropriate.

Looking at errors as just data avoids the "exceptional vs non-exceptional" hair splitting, and gives a lot of flexibility for code structure. I don't necessarily disagree with the Result type viewpoint as a return type from functions, but I also find it pretty pointless. Very often the best action is to separate out errors from successes into different tables immediately. A built-in Result type couples them, and encourages keeping them coupled.

Now you could argue that you can do that with Exceptions, too, by catching them immediately and treating them as data. In which case I want to ask "what's the point then?" and also refer to my topmost comment. Exceptions have a significant cost in infrastructure even if you don't actually use them...

What are you going to do with the errors once you have collected them?

What is the point of sorting or grouping them?

A simple example from the compiler I'm working on right now: I output type errors of expressions sorted by their location in the source file, instead of in the order they are detected. I also don't error out on the first one, but find all at once. I could also group warnings and errors together, output only the first N errors, or... whatever I fancy. Errors are just data.

Well, this example seems somewhat contrived to me because these errors are not the errors happening in the compiler, they are diagnostic messages describing the errors in the input data.

Any chance you have another example?

"An error happening in the compiler". What's that? If you mean a bug detected, then it should be handled with abort().

An error related to the file system, for example.

A file system error isn't an error happening in the compiler. The file system is an external system. So this error isn't really any different than a syntax error or type error. I would not treat it differently except making a different error message. Of course you cannot parse a file you cannot read, so there is a dependency which means that sooner or later you need to "act" on the error.

Well, grouping errors in your example makes sense when all of them happened during processing a particular input which is expected to be invalid sometimes.

Could you share another example where accumulating errors makes sense?

You can do it with anything. Analyze all the files in a directory, for instance. Do all the IO in parallel and merge the results at a central point. Some files might be corrupt or whatever. Merge the results at a central point. Only then present them to the user in a sensible order.

A real life example: Asynchronous webservers usually have worker threads for I/O. I/O errors need to be routed to the originators of the I/O requests (which are in other threads). Exceptions cannot do that.

Here's the general point: Whether any given thing is an "Error" is highly subjective and context dependent. But clearly the error is data, so why take away the possibility to process it like any other data?

This is an interesting conversation for me, but I still don't quite understand your reasoning.

IMO, using exceptions doesn't preclude treating errors as data.

In your example with parallel processing, you could throw an error as exception, let it unwind the whole stack, catch it and return as the result of the task.

This way you don't couple the code that does the useful work with the code that handles errors.

In other words, I don't understand why you dislike exceptions.

IMO they are a good tool for any task that doesn't require different actions to handle different errors.

Exceptions are not just data, at least not if you do not always catch them immediately (in which case they are just pointless).

They introduce additional control paths which are hard to reason about. In many languages these are not even explicit. Exceptions require an additional syntax to handle them. And having exceptions requires significant language infrastructure and comes with a huge toll on the structure of software projects. See my topmost comment.

> In your example with parallel processing, you could throw an error as exception, let it unwind the whole stack, catch it and return as the result of the task.

Which would catch only the first encountered error per thread. And not catch all the other errors that we could encounter and report after that.

Well, if you don't have exceptions, stack unwinding, RAII, you've got to manually code the same sort of logic using repetitive code. Or you would have to change your design to minimise the pain of hand-coding stack unwinding, most likely paying a price for that in form of damaging other aspects of design. In other words, NOT having exceptions, IMO, results in having to write a huge amount of code accomplishing a trivial task - aborting some unit of functionality upon unexpected error.

"And not catch all the other errors" I think, in most cases after an unexpected error happens it doesn't make sense to continue the task and report more errors, most likely induced by the first error.

Don't get me wrong, there are plenty of cases when returning errors as values is the best fit and using the exceptions would be a disaster, but my point is that, IMO, the situation when errors abort tasks and are handled in more or less the same way is much more common.

I think it's also how you should pick languages for a project. What is the worst yak-shaving aspect of the code you're going to have to write for this particular project? What language will go the furthest toward making that yak shaving go away? Pick that language.

I pick the languages based on the platform stack I have to use and not the other way around.

Basically the first class languages on a given platform, or having official bindings for a specific set of libraries that must be used.

My experience has proven it is the best path for lowest attrition.

Every time I decided to do otherwise I repented later on.

Reply on news.ycombinator.com