CollectionError enumv0.1.0

Why a collection operation could not be completed.

pub enum CollectionError: uint8 {
    OutOfMemory = 1,
    CapacityOverflow = 2,
    IndexOutOfRange = 3,
    Unsupported = 4
}

Every case means the operation did not happen and the collection is as it was.

Cases

Name	Value	Description
`OutOfMemory`	`1`	The allocator had no storage to give. Transient in principle: the same request may succeed later, and a caller with something to release may make it so.
`CapacityOverflow`	`2`	The size the operation needed could not be represented. A count times an element size that does not fit in a `uint`, or a length plus a growth that wraps. Not a shortage of memory but of arithmetic: no allocator could have served the request, because the number naming it does not exist.
`IndexOutOfRange`	`3`	The index was not one the collection has.
`Unsupported`	`4`	The allocator refused the layout itself rather than running short. An alignment stricter than the allocator serves, or a block it did not hand out. Retrying is pointless: the same request will be refused the same way.

Methods

`IsTransient`

pub func IsTransient(self: CollectionError) -> bool

Whether the same operation might succeed later. self is borrowed. True only for OutOfMemory, which says the allocator had nothing to give rather than that the request was impossible. A capacity that cannot be represented will not start being representable, an index the collection does not have will not appear, and a layout the allocator refuses will be refused again. Cannot fail. Runs in constant time and allocates nothing.

Returns: whether trying again could succeed

Source

Implements Display

CollectionError conforms to Display.

`WriteDisplay`

pub func WriteDisplay(
    self: &CollectionError,
    writer: &var TextWriter,
    spec: FormatSpec
) -> ! FormatError

Writes the description of why an operation did not happen, or no error for success. The five cases stay distinguishable in words as they are in the type: a shortage of memory is not a size that cannot be named, and neither is a layout the allocator refuses outright. Those distinctions decide whether a caller retries, so a description that blurred them would send somebody to fix the wrong thing. The descriptions are stable. They are not a parsing contract: a program branches on the case. Reports whatever the writer reported, and UnsupportedRequest for any style or precision.

Name	Type	Description
`writer`	`&var TextWriter`	the destination
`spec`	`FormatSpec`	what the placeholder asked for

Returns: success when the whole description was accepted

Source

Implements Debug

CollectionError conforms to Debug.

`WriteDebug`

pub func WriteDebug(
    self: &CollectionError,
    writer: &var TextWriter,
    spec: FormatSpec
) -> ! FormatError

Names the case, qualified by its type: CollectionError::OutOfMemory. Reports whatever the writer reported, and UnsupportedRequest for any style or precision.

Name	Type	Description
`writer`	`&var TextWriter`	the destination
`spec`	`FormatSpec`	what the placeholder asked for

Returns: success when the whole name was accepted

Source

`FromAllocError`

pub func FromAllocError(error: AllocError) -> CollectionError

The collection error that corresponds to an allocator's. error is read by value. OutOfMemory stays itself, and Unsupported and InvalidBlock both become Unsupported, because from a collection's side they are the same thing — the allocator will not serve this, and asking again will not change that. Cannot fail. Runs in constant time and allocates nothing.

Source

Parameters

Name	Type	Description
`error`	`AllocError`	why the allocator refused

Returns: the same failure as a collection error

BitSet

A growable set of bits.

Deque<T>

A double-ended queue over a circular buffer.

Edit this page on GitHub