Exception vs Errors | Chris Lattner and Lex Fridman

Please support this podcast by checking out our sponsors:

GUEST BIO:
Chris Lattner is a legendary software and hardware engineer, leading projects at Apple, Tesla, Google, SiFive, and Modular AI, including the development of Swift, LLVM, Clang, MLIR, CIRCT, TPUs, and Mojo.

PODCAST INFO:

SOCIAL:

[LexClips]

Guest bio: Chris Lattner is a legendary software and hardware engineer, leading projects at Apple, Tesla, Google, SiFive, and Modular AI, including the development of Swift, LLVM, Clang, MLIR, CIRCT, TPUs, and Mojo.

[quintrankid]

Nesting should be illegal? Wait until Lex hears about decorators.

[garanceadrosehn]

My favorite quote: *"The art of API design is actually really profound."*

[oracleoftroy]

This doesn't really do zero-cost exceptions justice.

As per usual, all that is compared is what happens when things go wrong. Yes, exceptions are much slower in that case. So, how often should things go wrong in a well written, normal piece of software? 80% error rate? 50%? 10%? 1%? Even less? If you are doing some operation and it is reasonably likely to fail, like say communicating over a network, it makes sense to not use exceptions. If it is extremely rare, exceptions start to make more sense.

Also there is the question of how much one cares about the performance cost of the error path. No one cares that it takes an extra millisecond to put up an error message just because you used exceptions. If the algoritm needs to be as fast as possible even when an error happens, sure something else is needed but in many cases the overhead of the error parh doesnt matter at all.

But here's the thing. What is the cost to turning every single operation into a branch? With exceptions, you write every operation as if it will succeed, no branching needed, then strategically use catch where it makes sense. Often you don't need to catch at all, or only at very high level places, as an exception means the whole operation failed. You let the app crash, or catch and report that whatever the user was trying to do failed. In the right situation, the branchless nature of zero cost exceptions is much faster than the alternatives.

In terms of complexity, I dont find exceptions harder to reason about than a return statement. You have no idea where a return is going to go, but it can only go somewhere up the callstack. It can't just jump anywhere. So too with exceptions. They don't magically jump just anywhere, but to an exception handler on the stack.

Whether or not using exceptions is the best choice is going to depend on the nature of the code and project, but they are a very useful tool in the right situation. At minimum, i find that they work well as a better assertion for things that ought never happen, but in theory could.

[leisti]

As the clip itself starts cold in the middle of an interview, it would be nice if at least the video description said something about what the clip is about. Who is talking? What is the subject?

[piotrjasielski]

Nesting is beautiful, powerful and profound. Programming without nesting is not programming and should be illegal.

[ben_clifford]

Well, this clip did what it was meant to do, which was to interest me in the full interview

[jacobstamm]

Wait, so it’s all nested functions?

Always has been.

[YellowCable]

...and yes nesting of functions should also never exist. It destroys opportunity for code reuse and prevents refactoring. A lot of language features have been developed "just because we can", but the large majority of language features should be not only ignored but actively avoided.

[anonlegion]

Lex sounds like he don't know about programming. Nesting functions is basically the premise of FN

[sebbbi]

People hate goto, but they are fine with hidden goto that you can’t clearly see by reading the code.

Writing code that is 100% exception safe is hard. It’s very easy to make subtle bugs that are difficult to find.

Rust returns errors. C returns errors. C++ exceptions are a messy exception. Nowadays it’s extremely easy to implement your own C++ error/value wrapper (similar to Rust).

[VivekNa]

Writing your code expecting that errors happen commonly is just silly
If something happens often its not an "Exception" - you would never use exceptions for flow control.

[yoavmor]

Python closures are disgusting. They're the only objects in the entire language that catch the local variables themselves by reference. Why the creators of Python decided to do it this way boggles my mind.

You can't even run [lambda: print(i) for i in range(70)] without all these closures getting bount to this i variable and as a result all of them print 69

[YellowCable]

Exceptions are a disaster, they actively make a programming language worse. It is very rarely documented which exact APIs are going to throw which excpetions,
and the error handling for code that needs to be reliable becomes basically impossibly complex to write.
Just return an error when an error occurs, exceptions solve exactly zero problems and create a vast number of them.

[JhonCoello-bl]

my moment is when say: "my opinions is..."

[lashlarue]

Nesting should be illegal? Yeesh, don't ever try looking into Uncle Bob's clean code manifesto.

[laughingvampire]

why didn't you talk about condition-restart system in common lisp?

[spiritualpolitics]

A little too in the weeds and did not quite address the more global question of Hey let's just get rid of errors altogether. What of the not having NULL debate? You mention Rust, I assume to consider that. A lot of missing points here.

[KenOtwell]

"Think about a function that doesn't return anything..." Uh.. functions are defined as code that ONLY returns things with no side effects. If you have a function that doesn't return anything, then it doesn't do anything whatsoever. Chris actually meant "method", not function. Of course, Python also labels methods as functions, so.... consistency is the hobgoblin of little minds?