LLMs are mortally terrified of exceptions

https://twitter.com/karpathy/status/1976077806443569355

by nought • 10 months ago

305 151 10 months ago

twitter.com

https://x.com/karpathy/status/1976082963382272334

mwkaufma2• 10 months ago

Even when they're not AI slop, these kinds of "paranoid sanity checks" are the software equivalent of security-theater.

bwfan123• 10 months ago

Form over function is what they are trained for. So, verbose commentary, needless readmes, and emojis all serve that purpose.

mwkaufma2• 10 months ago

Coding for the reviewer, not the user.

simonw• 10 months ago

Yeah, I really hate code like this because it generally ends up full of codepaths that have never been exercised, so there's all sorts of potential for weird behavior and unexpected edge cases. Plus it's harder to review.

dwd• 10 months ago

Sometimes security theater is what you need to not trigger a false positive on a static code analysis.

I haven't needed to use a service like Fortinet recently and am now wondering if a LLM is part of their tool and if it's better/worse?

shiandow• 10 months ago

Is there a way to read the rest?

hugo1789• 10 months ago

https://xcancel.com/karpathy/status/1976082963382272334

wffurr• 10 months ago

Turns out computer math is actually super hard. Basic operations entail all kinds of undefined behavior and such. This code is a bit verbose but otherwise familiar.

Den_VR• 10 months ago

If we wanted defined behavior we’d build systems with Karnaugh maps all the way down.

falcor844• 10 months ago

    # Step 3: Preemptively check for catastrophic magnitude differences
    if abs(a) > sys.float_info.max / 2:
        logging.warning("Value of a might cause overflow. Returning infinity just to be sure")
        return math.copysign (float('inf'), a)
    if abs(b) < sys.float_info.epsilon:
        logging.warning("Value of b dangerously close to zero. Returning NaN defensively.")
        return math.nan

Does the above code make any sense? I've not worked with this sort of stuff before, but it seems entirely unreasonable to me to check them individually. E.g. if 1 < b < a, then it seems insane to me to return float('inf') for a large but finite a.

im3w1l• 10 months ago

Ignoring the sign of b for big a can't be right.

vessenes• 10 months ago

It’s parody

josefx• 10 months ago

It also uses float epsilon and I don't think I have ever seen code where using it was appropriate.

OutOfHere• 10 months ago

Is this Claude? GPT is not like this. To me it looks like Anthropic is just maximizing billable token use as usual, and it has nothing really to do with exceptions per se.

TuxSH• 10 months ago

From the UI it indeed seems to be Claude

constantcrying• 10 months ago

If you are dividing two numbers with no prior knowledge of these numbers or any reasonable assumptions you can make and this code is used where you can not rely on the caller to catch an exception and the code is critical for the product, then this is necessary.

If you are actually doing safety critical software, e.g. aerospace, medicine or automotive, then this is a good precaution, although you will not be writing in Python.

mewpmewp2• 10 months ago

I might agree with that, and maybe the example posted by Karpathy is not the greatest, but what I'm constantly being faced with is try catches where it will fail silently or return a fallback/mock response, which essentially means that system will behave unexpectedly in a more subtle way down the line while leaving you clueless to as what the issue was.

I have to constantly remind Claude that we want to fail fast.

isoprophlex• 10 months ago

A good 10% of my Claude.md is yelling at it that no i don't want you to silently handle exceptions six calls deep into the stack and no please don't wrap my return values in weird classes full of dumb status enums "for safety"

Just raise god damn it

hyperpape• 10 months ago

I'm not sure returning None is any safer than an Exception, because the caller still has to check.

metalcrow• 10 months ago

Given that the output describes the function as being done "with extraordinary caution, because you never know what can go wrong", i would guess that the undisclosed prompt was something similar to "generate a division function in python that handles all possible edges cases. be extremely careful". Which seems to say less about LLM training and more about them doing exactly what they are told.

freehorse• 10 months ago

Aside from the absurdity and obvious satirical intention,

1. the code is actually wrong (and is wrong regardless of the absurd exception handling situation)

2. some of the exception handling makes no sense regardless, or is incoherent

3. a less absurd version of this actually happens (edit: commonly in actual irl scenarios) if you put emphasis on exception handling in the prompt

angry_albatross• 10 months ago

I interpreted the function code as being a deliberately exaggerated satirical example that was illustrative of the experience he was having. So yes, in that example it was probably told to be overly cautious, but I agree with him that the default of LLMs seems to be a bit more cautious than I would like.

sarchertech• 10 months ago

Expert beginners program like this. I call it what it driven development. Turns out a lot of code was written by expert beginners because by many metrics they are prolifically productive.

In go all SOTA agents are obsessed with being ludicrously defensive against concurrency bugs. Probably because in addition to what if driven development, there are a lot of blog posts warning about concurrency bugs.

bobogei81123• 10 months ago

This is just AI trying to tell us how bad we designed our programming languages to be when exceptions can be thrown pretty much anywhere

recursive• 10 months ago

So you think java's checked exceptions are a better model? No opinion myself, but that way seems widely considered bad too.

nivertech8• 10 months ago

Why do you need exceptions at all? They’re just a different return types in disguise…

Also, division by zero should return Inf

Terr_• 10 months ago

So you think java's checked exceptions are a better model?

Checked Exceptions are a good concept which just needed more syntactic-sugar. (Like easily specifying that one kind of exception should be wrapped into another.) The badness is not in the logic but in the ecology, the ways that junior/lazy developers are incentivized to take horrible shortcuts.

Checked exceptions are fundamentally the same as managing the types of return-values... except the language doesn't permit the same horrible-shortcuts for people to abuse.

Meme reaction: http://imgur.com/iYE5nLA

_____

Prior discussion: https://news.ycombinator.com/item?id=42946597

criemen• 10 months ago

It's also logically incoherent - division by zero can't occur, because if b=0 then abs(b) < sys.float_info.epsilon.

Furthermore, the code is happy to return NaN from the pre-checks, but replaces a NaN result from the division by None. That doesn't make any sense from an API design standpoint.

dijksterhuis• 10 months ago

I mean, the first three cases are just attempting to turn dynamic into static typed... right? maybe just don't aim for uber-safety in a dynamically typed language? :shrugs:

(I used to look out for kaparthy's papers ten years ago... i tend to let out an audible sigh when i see his name today)

falcor844• 10 months ago

You shouldn't have the same expectations from a person's tweet as you would from a paper. I don't see any issue with high profile people who are careful in their professional work, putting less thought-through output on social media. At least as long as they don't intentionally/negligently spreading misinformation, which I've never seen Karpathy do.

I for one really enjoy both his longer form work and his shorter takes.

falcor844• 10 months ago

That code has many issues, but the one that bothers me the most in practice is this tendency of adding imports inside functions. I can only assume that it's an artifact of them optimizing for a minimal number of edits somewhere in the process, but I expect better.

kccqzy• 10 months ago

It's to make imports lazy, to solve the issue of slow import at startup.

falcor844• 10 months ago

While there are some cases where lazy imports are appropriate, this function, and the vast majority of such lazy imports that I get from Claude are not.

In particular, I can't think of any non-pathological situation where a python developer should import logging and update logging.basicConfig within an inner function.

Maxion• 10 months ago

It's also a trick in python to deal with circular imports.

jamster02• 10 months ago

I also recently ran into a problem when unit testing and monkey patching where I had to import after monkey patching, so in the function itself.

andrewmcwatters• 10 months ago

In very, very large projects, you end up finding that you want lazy initialization as much as possible, because it greatly affects startup times.

natnat• 10 months ago

I think this has a lot to do with the mechanism of RoPE attention, where physical closeness in the code is a signal of relevance.

jpcompartir• 10 months ago

Most comments seem to be taking the code seriously, when it's clearly satirical?

fkyoureadthedoc• 10 months ago

Not sure why but it made me think of FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

ineedasername• 10 months ago

Woah, were they using junit 4.8.3 in that project? Someone was flying by the seat of their pants, I hope they got sign-off on that by legal & the CTO, that’s the kind of cowboy coding choice that can hurt a career.

stefanfisk• 10 months ago

PRs are welcome!

lawlessone• 10 months ago

...so many folder and files , i feel damaged after seeing that.

Great satire.

glitchc• 10 months ago

But what's the prompt that led to this output? Is it just a simple "Write code to divide a by b?" or are there instructions added for code safety or specific behaviours?

I know it's Karpathy, which is why the entire prompt is all the more important to see.

johnisgood• 10 months ago

"Write me a code that divides a by b and make sure it is safe and handles all edge cases"[1] or something and some languages have more than others.

[1] Probably with some "make you sure handle ALL cases in existence", or emphasis, along those lines.

stargrazer• 10 months ago

but then, why code with exceptions, why not perform pre-flight/pre-validation checks and minimize exceptions to the truly unknown?

jampekka• 10 months ago

I've noted that LLMs tend to produce defensive code to a fault. Lots of unnecessary checks, e.g. check for null/None/undefined multiple times for same valie. This can lead to really hard to read code, even for the LLM itself.

The RL objectives probably heavily penalize exceptions, but don't reward much for code readability or simplicity.

MakeAJiraTicket3• 10 months ago

I have a function that compares letters to numbers for the Major System and it's like 40 lines of code and copilot starts trying to add "guard rails" for "future proofing" as if we're adding more numbers or letters in the future.

It's so annoying.

comex2• 10 months ago

This is a parody but the phenomenon is real.

My uninformed suspicion is that this kind of defensive programming somehow improves performance during RLVR. Perhaps the model sometimes comes up with programs that are buggy enough to emit exceptions, but close enough to correct that they produce the right answer after swallowing the exceptions. So the model learns that swallowing exceptions sometimes improves its reward. It also learns that swallowing exceptions rarely reduces its reward, because if the model does come up with fully correct code, that code usually won’t raise exceptions in the first place (at least not in the test cases it’s being judged on), so adding exception swallowing won’t fail the tests even if it’s theoretically incorrect.

Again, this is pure speculation. Even if I’m right, I’m sure another part of the reason is just that the training set contains a lot of code written by human beginners, who also like to ignore errors.

MakeAJiraTicket3• 10 months ago

Defensive programming is considered "correct" by the people doing the reinforcing, and is a huge part of the corpus that LLM's are trained on. For example, most python code doesn't do manual index management, so when it sees manual index management it is much more likely to freak out and hallucinate a bug. It will randomly promote "silent failure" even when a "silent failure" results in things like infinite loops, because it was trained on a lot of tutorial python code and "industry standard" gets more reinforcement during training.

These aren't operating on reward functions because there's no internal model to reward. It's word prediction, there's no intelligence.

comex2• 10 months ago

Reinforcement learning by definition operates on reward functions.

LeifCarrotson• 10 months ago

LLMs do use simple "word prediction" in the pretraining step, just ingesting huge quantities of existing data. But that's not what LLM companies are shipping to end users.

Subsequently, ChatGPT/Claude/Gemini/etc will go through additional training with supervised fine-tuning, reinforcement learning with reward functions whether human-supervised feedback (RLHF) or reward functions (RLVR, 'verified rewards').

Whether that fine-tuning and reward function generation give them real "intelligence" is open to interpretation, but it's not 100% plagarism.

aoeusnth1• 10 months ago

You used the word reinforcing, and then asserted there's no reward function. Can you explain how it's possible to perform RL without a reward function, and how the LLM training process maps to that?

rsynnott2• 10 months ago

The great Verity Stob (unfortunately, in an article which no longer seems to be online, after the Dr Dobbs Journal website finally went away) referred to this behaviour (by _human_ programmers) as "nailing the corpse in an upright position".

automatic6131• 10 months ago

https://97-things-every-x-should-know.gitbooks.io/97-things-...

btown• 10 months ago

My suspicion is that the training set features a lot of code with “positive sentiment” in text and comments around it… but where does one find code with “negative” sentiment, followed by code that is the “corrected” version of that code? In programs written for technical interview prep, where handling of edge cases beyond realistic production situations is the norm. A model trained to use negative examples in its training set as guidance would gravitate away from examples that skip exception handling.

In this, at least, AI may very well have copied our worst habits of “learning to the test.”

karpathy• 10 months ago

Sorry I thought it would be clear and could have clarified that the code itself is just a joke illustrating the point, as an exaggeration. This was the thread if anyone is interested

https://chatgpt.com/share/68e82db9-7a28-8007-9a99-bc6f0010d1...

chis• 10 months ago

I think there’s always a danger of these foundational model companies doing RLHF on non-expert users, and this feels like a case of that.

The AIs in general feel really focused on making the user happy - your example, and another one is how they love adding emojis to the stout and over-commenting simple code.

cma2• 10 months ago

And more advanced users are more likely to opt out of training on their data, Google gets around it with a free api period where you can't opt out and I think from did some of that too, through partnerships with tool companies, but not sure if you can ever opt out there.

miki123211• 10 months ago

This feels like RLVR, not RLHF.

With RLVR, the LLM is trained to pursue "verified rewards." On coding tasks, the reward is usually something like the percentage of passing tests.

Let's say you have some code that iterates over a set of files and does processing on them. The way a normal dev would write it, an exception in that code would crash the entire program. If you swallow and log the exception, however, you can continue processing the remaining files. This is an easy way to get "number of files successfully processed" up, without actually making your code any better.

justatdotin• 10 months ago

'over-commenting simple code' is preparing it for future agent work. pay attention to those comments to learn how you can better scaffold for agents.

why_at• 10 months ago

This part from the first try made me laugh:

      if random.random() < 0.01:

          logging.warning("This feels wrong. Aborting just in case.")

          return None

bspammer• 10 months ago

I think that’s the funniest joke I’ve ever seen an LLM make. Which probably means it’s copied from somewhere.

x187463• 10 months ago

I actually laughed when I read that. This one got me, too. The casual validation of its paranoia gives me Marvin the Paranoid Android vibes.

  try:
      result = a / b
      if math.isnan(result):
          raise ArithmeticError("Result is NaN. I knew this would happen.")

tomjakubowski• 10 months ago

Years and years ago, the MongoDB Java driver had something like this to skip logging sometimes in one of its error handling routines.

   } catch (Exception e) {
                if (!((_ok) ? true : (Math.random() > 0.1))) {
                    return res;
                }

                final StringBuilder logError = (new StringBuilder("Server seen down: ")).append(_addr);

                /* edited for brevity: log the error */

https://github.com/mongodb/mongo-java-driver/blob/1d2e6faa80...

bjourne2• 10 months ago

This is stunning English: "Perfect setup for satire. Here’s a Python function that fully commits to the bit — a traumatically over-trained LLM trying to divide numbers while avoiding any conceivable danger:" "Traumatically over-trained", while scoring zero google hits, is an amazingly good description. How can it intuitively know what "traumatic over-training" should mean for LLMs without ever having been taught the concept?

drekipus• 10 months ago

The same way that you and I think up a word and what it might mean without being taught the concept.

Adverb + verb

gnulinux• 10 months ago

Hard to know but if you could express "traumatically" as a number, and "over-trained" as a number, it seems like we'd expect "traumatically" + "over-trained" to be close to "traumatically over-trained" as a number. LLMs work in mysterious ways.

jcelerier• 10 months ago

LLMs operate at token level, not word. it doesn't operate in terms of "traumatic", "over-training", "over" or "training", but rather "tr" "aum" "at" "ic, ", etc.

shawabawa3• 10 months ago

How can it intuitively know what "traumatic over-training" should mean for LLMs without ever having been taught the concept?

Because, and this is a hot take, LLMs have emergent intelligence

mahogany• 10 months ago

“Traumatic overtraining” does have hits though. My guess is that “traumatically” is a rarely used adverb, and “traumatic” is much more common. Possibly it completed traumatic into an adverb and then linked to overtraining which is in the training data. I dunno how these things work though.

bccdee2• 10 months ago

I don't know. It's a classic LLM-ism. "Traumatically over-X" is probably a common enough phrase. The prmpt says, "I don't know what labs are doing to these poor LLMs during RL," so the model connects that to some form of trauma. The training is traumatic, so the model is traumatically over-trained.

It sounds fine and flows nicely, but it doesn't quite make sense. Too much training over-fits an LLM; that's not what we're describing. Bad training might traumatize a model, but bad how? A creative response would suggest an answer to that question—perhaps the model has been made paranoid, scarred by repeat exposure to the subtlest and most severe bugs ever discovered—but the LLM isn't being creative. Its response has that spongy, plastic LLM texture that comes from the model rephrasing its prompt to provide a sycophantic preamble for the thing that was actually being asked for. It uses new words for the same old idea, and a bit of the precision is lost during the translation.

chipsrafferty2• 10 months ago

You need to read more if you think that's stunning English

cruffle_duffle• 10 months ago

Kind of interesting it didn't add type hints though! You'd think for all that paranoia it would at least add type hints.

TZubiri2• 10 months ago

https://chatgpt.com/share/68e87072-e3ac-800f-a44c-af5666180a...

lgtm

nought• 10 months ago

It was a great joke, that's why I posted it

ziml772• 10 months ago

That's funny but definitely not far off from reality. I have instructions from my agent to use exceptions but they only help so much.

I really dislike their underuse of exceptions. I'm working on ETL/ELT scripts. Just let stuff blow up on me if something is wrong. Like, that config entry "foo" is required. There's no point in using config.get("foo") with a None check which then prints a message and returns False or whatever. Just use config["foo"] and I'll know what's wrong from the stack trace and exception text.

ziml772• 10 months ago

Aaaand there we go. I literally just ran into a problem with code someone had used AI to write which does this log and continue nonsense. Process spent 30 minutes looping through API requests and failing to persist the response on every single one because of a permission error. But the only indication of a problem is the errors in the log, the process finished with a successful exit code.

CGamesPlay• 10 months ago

I dealt with this in my AGENTS.md by including a recap of the text of "Vexing Exceptions" [0], rephrased as a set of guidelines for when to write a throw or catch. I feel like it helped; and when it still emits error handling I disagree with and I ask about it, it will categorize it into one of the four categories, and typically rewrite it in an appropriate way.

I think the Vexing Exceptions post is on the same tier as other seminal works in computer science; definitely worth a quick read or re-read once in a while.

[0] https://ericlippert.com/2008/09/10/vexing-exceptions/

furyofantares• 10 months ago

A couple thoughts.

One is that often I do want error handling, but also often I either know the error just won't happen or if it does, something is very wrong and we should just crash fast to make it easy to fix the bug.

But I am not really sure I would expect someone to know the difference in all cases just looking at some code. This is often an about holistically knowing how the app works.

A second thought - remember the experiment where an LLM was fine tuned on bad code (exploitable security problems for example) and the LLM became broadly misaligned on all sorts of unrelated (non-coding) tasks/contexts? It's as if "good or bad" alignment is encoded as a pretty general concept.

Error-handling is good aligned, which I think is why, even with lots of instructions to fail fast, it's still hard to get the LLM to allow crashing by avoiding error checking. It's gonna be even harder if you do want it to do some error checking, and the code it's looking at has some error checking

exasperaited• 10 months ago

Why do LLMs do it for real: because you trained them by stealing all of Stack Overflow?

Less sarcastically but equally as true: they've learned from the tests you stole from people on the internet as well as the code you stole from people on the internet.

Most developers write tests for the wrong things, and many developers write tests that contain some bullshit edge case that they've been told to test (automatically to meet some coverage metric, or by a "senior" developer who got Dilbert principled away from the coalface and doesn't understand diminishing returns).

But then the end goal is to turn out code about as good as the average developer so they can be replaced more cheaply, so your LLM is meeting its objectives. Congrats.

iagooar• 10 months ago

This issue has been one of the biggest issues with the Claude models, not so much with GPT-4 or GPT-5.

I even had this Cursor rule when I was using Claude:

"- Do not use statements to catch all possible errors to mask an error - let it crash, to see what happened and for easier debugging."

And even with this rule, Claude would not always adhere. Never had this issue with GPT-5.

bhl• 10 months ago

What’s the solution here, reward code that works without try catch, reward code that errors and is caught, but penalize code that has try catch and never throws an error?

never_inline• 10 months ago

I think too much of RLHF is done on small scale tutorial-ish examples.

LLMs often write tutorial-ish code without much care how it integrates with rest of codebase.

Swallowing exceptions is one such example.

dgan2• 10 months ago

I spent more time dismissing various popups than reading this post. I hate twitter links

mcintyre1994• 10 months ago

Just add “cancel” after the x to get a viewable version of any Twitter link: https://xcancel.com/karpathy/status/1976082963382272334

leumon• 10 months ago

Or use the 'privacy redirect' extension which lets you specify your preferred nitter instance. It also works for other platforms.

dgan2• 10 months ago

Wow this is so much better user experience

cess11• 10 months ago

Now this is a toy example because usually you never do division this way, but in mature code in commercial applications this is usually what it looks like. It's a sliver of business logic that in itself seems trivial, and then handlers of edge case upon edge case upon edge case, mirroring an even larger set of unit tests.

One reason for this is that you typically lack a type system that allows 'making illegal states unrepresentable' to some extent, or possibly lack a team that can leverage the available type system to that effect due to organisational pressure, insufficient experience or whatever.

classified• 10 months ago

I'd love to see an LLM shake with fear and beg for mercy.

blitzar• 10 months ago

I figured this is how the pros write their code and I have been holding the code wrong the whole time.

beepdyboop• 10 months ago

Love this, but I do struggle with this same problem! How do we circumvent it?

stuaxo2• 10 months ago

My wishlist top item is to stop creating a class with Service on the name and having things come off it, when all I needed was functions and methods, the dev I was working with submitted a lot of these and in testing I could get the LLM to do it easily myself.

paulhodge• 10 months ago

Agree that LLMs go too far on error catching..

BUT, to play devil's advocate a little: Most human coders should be writing a lot more try/catch blocks than they actually do. It's very common that you don't actually want an error in one section (however unlikely) to interrupt the overall operation. (and sometimes you do, it just depends)

winddude• 10 months ago

but like a normal dev no unit test.

LLMs are mortally terrified of exceptions

Related Stories