in reply to Federico Mena Quintero

mastodon - Link to source

Kat Marchán 🐈

as a library author, my rule of thumb is that short of memory corruption issues (like out-of-bounds access), everything should be user-recoverable. Anything that would signal an incorrect internal assumption ("I am asserting to myself, as library author, that this invariant can never be violated") should immediately panic and never expose that failure to the user.
in reply to Kat Marchán 🐈

mastodon - Link to source

Federico Mena Quintero

@zkat Oh, yeah, I'm not talking about programming errors. I'm trying to distinguish two cases:

- something happened in this heavily recursive thing which should result in just not rendering an element (e.g. a transformation matrix ends up being non-invertible, no big deal, just not render the object and continue).

- OOM, or an implementation limit was exceeded - catch it, exit quickly, report an error in the public API.

@Kat Marchán 🐈
in reply to Federico Mena Quintero

mastodon - Link to source

Kat Marchán 🐈

@federicomena

  • GUI programming definitely has different requirements, where showing something at all is generally considered better than not showing anything (see also: it makes sense for JavaScript to be so loosey-goosey about types and conversions)
  • There's... a lot to be said in the debate on whether the modern assumption of "memory is infinite" and allocators being optimistic has been a good idea all these years, or whether we should exercise more control over our allocators.
@Federico Mena Quintero
⇧