9 ms·

A &(dyn Error + 'static) should be fine for that; you don't need any allocated/variable sized data in a memory allocation failure.

dnautics 5mo ago
stacktraces? might also be useful to know whether or not the latest allocand was a jumbo sized allocand that caused the failure?
- dwattttt 5mo ago
  Do you really want that data passed back down to the caller of the allocation? From the description of the failure state you'd want to log that data instead: what's the caller of the allocation going to do if you tell it it failed with a crazy size? It already knows the size, it's the one who asked for it.
  - dnautics 5mo ago
    So, suppose it's a rust library -- you're locking me into whatever logging system the library author chooses? Maybe I'd like to consume the relevant data at the entry point and send it to a logging system of my choice.
    - cobbzilla 5mo ago
      usually “stdout” is good enough, wrapper/runner routes output to logserver for collation and search. who cares about formats as long as it’s reasonably structured and searchable?
    - sheept 5mo ago
      A Rust library likely wouldn't be returning an opaque Box<dyn Error> to begin with. Errors are part of a library's API—it's what allows consumers to handle them—so you'd define an enum of possible errors your library could produce and return that, which would be stored on the stack.
      - dnautics 5mo ago
        What about the data in the error payload?
        yuriks 5mo ago
        That's part of the error enum. enum AllocError { SizeTooLarge { size: usize }, // etc. } This enum has a known size and doesn't require any dynamic allocations.
        dwattttt 5mo ago
        I think this is a clash of terminology: a Rust enum isn't an integer with pretensions of an identity. You'd describe it as a tagged union in some languages. So when you say you'd return an error with extra information, what that information is is associated with the specific variant of the enum. Using yuriks AllocError as an example, if the error is SizeTooLarge, it has the size field. Other errors may have no additional data, others may have different data. When you return an error from your allocating function, it's a known size, the size of the largest enum variant + the discriminant (tag).
        dnautics 5mo ago
        I'm aware that a rust enum isn't just an integer? How would it have a payload if it were just an integer? right. If allocerror only has size field, where do you stash the unwind information (which could be of arbitrary size)
        dwattttt 5mo ago
        There's a few confusing things here. For one, just because the allocator gave you an AllocError, that doesn't mean your function has to return an AllocError: you can return whatever error type you choose. If you want to collect a stack trace at that point, put one in there. What value would a stack trace that includes internal allocator functions be to you? What do you lose by having to collect the stack trace at the point where your function receives an AllocError?
    - pas 5mo ago
      it depends, if the functionality represented by the library is known to require a lot of memory (or simply allocation failures are an expected part of its operation), then it should be pretty much part of the API, probably with some tracing/diagnostics interface to get the required visibility into how much memory goes and where. but for most libraries I on allocation failure I don't expect any fancy logging system. maybe even panic is fine.
- 63stack 5mo ago
  Any time I mention "but I would like stacktraces with my errors" I get told I'm doing it wrong.
  - simonask 5mo ago
    That's because the types of errors where you want a stack trace are a relatively small subset of all possible errors. Stack traces are only useful for errors that indicate a bug in the program, i.e. something a programmers has to respond to. It's not useful for the vast class of bugs that are a result of wrong input, wrong external state, or infrastructure issues. Rust projects tend to favor panicking over error handling for programmer bugs (which does indeed give you a stack trace depending on environment variables), or even better encoding the invariants in the type system, but there are cases where an error coming from a library are truly, actually unexpected, so both `anyhow` and `thiserror` do provide support for attaching a stack trace in those situations.
    - 63stack 5mo ago
      See? You get people explaining to you that you actually don't want a stack trace because xyz.
      - wtetzner 5mo ago
        This sounds disingenuous. They explained why the language doesn't force stack traces on all errors, and then explained how to get them if you want them.
        63stack 5mo ago
        I see a very opinionated explanation, not a "this is why the language does not" explanation. >Stack traces are only useful for errors that indicate a bug in the program, i.e. something a programmers has to respond to. It's not useful for the vast class of bugs that are a result of wrong input, wrong external state, or infrastructure issues. This is a personal opinion, not something you can declare as the objective truth. There is a lot of value in seeing what path the program took before it encountered a eg. validation error. >but there are cases where an error coming from a library are truly, actually unexpected, so both `anyhow` and `thiserror` do provide support for attaching a stack trace in those situations. This is wrong because it's up to the library to attach the stacktrace, not the userland code using the library, so saying "you can get them if you want them" is not true. If the author of the library did not decide to attach the stacktrace, your only option is wrapping it yourself, which you can only do if you already know up front all the paths that can fail. Also, you are not supposed to expose errors from a library with anyhow, they are only for application/top level code.
- SkiFire13 5mo ago
  And how do you store a stacktrace without allocating?
- imtringued 5mo ago
  If you let the allocation error panic you will get your stack trace. You can't have a stack trace on an error in the error path that failed to allocate. If you have a "jumbo sized" error and the error fails to allocate, it won't get reported. The only reporting you will get is that the error failed to allocate and this new allocation error overrides the error that failed to allocate.
- mswphd 5mo ago
  if you have an OOM and want to log why, if your logging allocates it will likely fail as well. You could in principle work around this with enough effort, but "properly" handling OOM is typically much more trouble than its worth.

dnautics 5mo ago

stacktraces? might also be useful to know whether or not the latest allocand was a jumbo sized allocand that caused the failure?

dwattttt 5mo ago
Do you really want that data passed back down to the caller of the allocation? From the description of the failure state you'd want to log that data instead: what's the caller of the allocation going to do if you tell it it failed with a crazy size? It already knows the size, it's the one who asked for it.
- dnautics 5mo ago
  So, suppose it's a rust library -- you're locking me into whatever logging system the library author chooses? Maybe I'd like to consume the relevant data at the entry point and send it to a logging system of my choice.
  - cobbzilla 5mo ago
    usually “stdout” is good enough, wrapper/runner routes output to logserver for collation and search. who cares about formats as long as it’s reasonably structured and searchable?
  - sheept 5mo ago
    A Rust library likely wouldn't be returning an opaque Box<dyn Error> to begin with. Errors are part of a library's API—it's what allows consumers to handle them—so you'd define an enum of possible errors your library could produce and return that, which would be stored on the stack.
    - dnautics 5mo ago
      What about the data in the error payload?
      - yuriks 5mo ago
        That's part of the error enum. enum AllocError { SizeTooLarge { size: usize }, // etc. } This enum has a known size and doesn't require any dynamic allocations.
      - dwattttt 5mo ago
        I think this is a clash of terminology: a Rust enum isn't an integer with pretensions of an identity. You'd describe it as a tagged union in some languages. So when you say you'd return an error with extra information, what that information is is associated with the specific variant of the enum. Using yuriks AllocError as an example, if the error is SizeTooLarge, it has the size field. Other errors may have no additional data, others may have different data. When you return an error from your allocating function, it's a known size, the size of the largest enum variant + the discriminant (tag).
        dnautics 5mo ago
        I'm aware that a rust enum isn't just an integer? How would it have a payload if it were just an integer? right. If allocerror only has size field, where do you stash the unwind information (which could be of arbitrary size)
        dwattttt 5mo ago
        There's a few confusing things here. For one, just because the allocator gave you an AllocError, that doesn't mean your function has to return an AllocError: you can return whatever error type you choose. If you want to collect a stack trace at that point, put one in there. What value would a stack trace that includes internal allocator functions be to you? What do you lose by having to collect the stack trace at the point where your function receives an AllocError?
  - pas 5mo ago
    it depends, if the functionality represented by the library is known to require a lot of memory (or simply allocation failures are an expected part of its operation), then it should be pretty much part of the API, probably with some tracing/diagnostics interface to get the required visibility into how much memory goes and where. but for most libraries I on allocation failure I don't expect any fancy logging system. maybe even panic is fine.
63stack 5mo ago
Any time I mention "but I would like stacktraces with my errors" I get told I'm doing it wrong.
- simonask 5mo ago
  That's because the types of errors where you want a stack trace are a relatively small subset of all possible errors. Stack traces are only useful for errors that indicate a bug in the program, i.e. something a programmers has to respond to. It's not useful for the vast class of bugs that are a result of wrong input, wrong external state, or infrastructure issues. Rust projects tend to favor panicking over error handling for programmer bugs (which does indeed give you a stack trace depending on environment variables), or even better encoding the invariants in the type system, but there are cases where an error coming from a library are truly, actually unexpected, so both `anyhow` and `thiserror` do provide support for attaching a stack trace in those situations.
  - 63stack 5mo ago
    See? You get people explaining to you that you actually don't want a stack trace because xyz.
    - wtetzner 5mo ago
      This sounds disingenuous. They explained why the language doesn't force stack traces on all errors, and then explained how to get them if you want them.
      - 63stack 5mo ago
        I see a very opinionated explanation, not a "this is why the language does not" explanation. >Stack traces are only useful for errors that indicate a bug in the program, i.e. something a programmers has to respond to. It's not useful for the vast class of bugs that are a result of wrong input, wrong external state, or infrastructure issues. This is a personal opinion, not something you can declare as the objective truth. There is a lot of value in seeing what path the program took before it encountered a eg. validation error. >but there are cases where an error coming from a library are truly, actually unexpected, so both `anyhow` and `thiserror` do provide support for attaching a stack trace in those situations. This is wrong because it's up to the library to attach the stacktrace, not the userland code using the library, so saying "you can get them if you want them" is not true. If the author of the library did not decide to attach the stacktrace, your only option is wrapping it yourself, which you can only do if you already know up front all the paths that can fail. Also, you are not supposed to expose errors from a library with anyhow, they are only for application/top level code.
SkiFire13 5mo ago
And how do you store a stacktrace without allocating?
imtringued 5mo ago
If you let the allocation error panic you will get your stack trace. You can't have a stack trace on an error in the error path that failed to allocate. If you have a "jumbo sized" error and the error fails to allocate, it won't get reported. The only reporting you will get is that the error failed to allocate and this new allocation error overrides the error that failed to allocate.
mswphd 5mo ago
if you have an OOM and want to log why, if your logging allocates it will likely fail as well. You could in principle work around this with enough effort, but "properly" handling OOM is typically much more trouble than its worth.