3 ms·

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: wh

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?
    - echelon 5mo ago
      You can do better than the errors in other languages. You can provide all the relevant information in the emum variant. enum MyApiBindingCrateError { // You didn't provide an // API key. Maybe we should // design our interface to // make this impossible ApiKeyMissing, // Client was unauthorized // to make this request AuthorizationError, // The entity you requested // did not exist (404'd) NotFoundError, // You're sending too many // requests to the server TooManyRequests, // That specific error with // the API // Maybe users can't delete // folders until they're empty // Whatever SpecificApiIssue1, // Some other specific error // with the API SpecificApiError2, // Server didn't respond the // way we expected. // Here's what it told us UnexpectedHttpResponse { // HTTP status code status_code: StatusCode, // If it had a // string-encoded body body: Option<String>, }, // Unhandled Issue with IO IoError(io::Error), // Unhandled Issue with // request library ReqwestError(reqwest::Error), } The beauty with Rust is that you can create really detailed concrete errors at the crate level. Your callers will know exactly what the actual error states are. Your application can be a little less structured if you want. Though with LLMs, I'm using anyhow and thiserror a lot less.
      - imtringued 5mo ago
        In the current context with regards to failed allocations, you're also supposed to add a variant that wraps 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.

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?
  - echelon 5mo ago
    You can do better than the errors in other languages. You can provide all the relevant information in the emum variant. enum MyApiBindingCrateError { // You didn't provide an // API key. Maybe we should // design our interface to // make this impossible ApiKeyMissing, // Client was unauthorized // to make this request AuthorizationError, // The entity you requested // did not exist (404'd) NotFoundError, // You're sending too many // requests to the server TooManyRequests, // That specific error with // the API // Maybe users can't delete // folders until they're empty // Whatever SpecificApiIssue1, // Some other specific error // with the API SpecificApiError2, // Server didn't respond the // way we expected. // Here's what it told us UnexpectedHttpResponse { // HTTP status code status_code: StatusCode, // If it had a // string-encoded body body: Option<String>, }, // Unhandled Issue with IO IoError(io::Error), // Unhandled Issue with // request library ReqwestError(reqwest::Error), } The beauty with Rust is that you can create really detailed concrete errors at the crate level. Your callers will know exactly what the actual error states are. Your application can be a little less structured if you want. Though with LLMs, I'm using anyhow and thiserror a lot less.
    - imtringued 5mo ago
      In the current context with regards to failed allocations, you're also supposed to add a variant that wraps 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.