CODEWITHSUNDEEP
c#queue
Mauricio Gracia Gutierrez
Mauricio Gracia Gutierrez

Reputation: 10844

What exceptions/errors can happen when calling Queue.Enqueue method

In the MSDN and Intellisense info there is no mention of any Exception that is thrown when calling Queue.Enqueue method

But since MSDN says

.....As elements are added to a Queue, the capacity is automatically increased as required through reallocation

I guess it can failed because there is not enough memory to hold the new element.

What other errors can happen when callin Queue.Enqueue method ? Maybe the answer could include a LINK to documentation that list all of them for this particular method

How can I catch/handle the OutOfMemoryException when calling that method even though is not being thrown ? (Even if I can not recover from the OutOfMemory error I want to log it)

And by "not being thrown" I mean that

In the documentation of any method it always mentions what exceptions can be thrown by that method, but for that particular method is either not documented or it does not throw any exception. I want to know which one it is

Upvotes: 1

Views: 2699

Answers (3)

RB.
RB.

Reputation: 37192

Here is the disassembly of the Enqueue method (taken from ILSpy)

public void Enqueue(T item)
{
    if (this._size == this._array.Length)
    {
        int num = (int)((long)this._array.Length * 200L / 100L);
        if (num < this._array.Length + 4)
        {
            num = this._array.Length + 4;
        }
        this.SetCapacity(num);
    }
    this._array[this._tail] = item;
    this._tail = (this._tail + 1) % this._array.Length;
    this._size++;
    this._version++;
}

private void SetCapacity(int capacity)
{
    T[] array = new T[capacity];
    if (this._size > 0)
    {
        if (this._head < this._tail)
        {
            Array.Copy(this._array, this._head, array, 0, this._size);
        }
        else
        {
            Array.Copy(this._array, this._head, array, 0, this._array.Length - this._head);
            Array.Copy(this._array, 0, array, this._array.Length - this._head, this._tail);
        }
    }
    this._array = array;
    this._head = 0;
    this._tail = ((this._size == capacity) ? 0 : this._size);
    this._version++;
}

As you can see, it's pretty straightforward. You could get a StackOverflowException, or an OutOfMemoryException because you can always potentially get these.

Apart from that, it's not clear that anything could go wrong. You'd need to verify that there was no possibility of a NullPointerException by validating the various checks and guard clauses in the rest of the code, but a cursory glance suggests it is likely this will not occur. Of course, if you start using reflection you could always force a NullPointerException to throw.

I don't know if this will help you, but I believe it answers the question you've asked.

Upvotes: 1

RB.
RB.

Reputation: 37192

Having seen your edit, the question makes a bit more sense.

The MSDN documentation does not ordinarily document that OutOfMemoryException can be thrown as, basically, any method call could throw it (any method that allocates memory anyway - which is pretty much all of them!). Therefore, you can assume that it can be thrown in this case.

To clarify the situation with catching exceptions, imagine this bit of code:

  try
  {
      throw new ArgumentNullException();
  }
  catch (ArgumentOutOfRangeException)
  { 
      // This can never happen, but is perfectly legal code.
  }

The catch block will never be entered, but the compiler is perfectly happy with this code - it won't even issue a warning.

Upvotes: 0

Scott Chamberlain
Scott Chamberlain

Reputation: 127563

If your only goal is to catch all possible execptions and log them and do nothing else it is actually quite simple to do.

try
{
    queue.Enqueue(foo);
}
catch (Exception ex)
{
    LoggingMethod(ex);
    throw;
}

What that will do is catch all exceptions that are possible to catch (OutOfMemory is one of the few you may not be able to), log it, then re-throw the exception while preserving the original stack trace so the code this snippet resides in can handle it if necessary.

Do not do throw ex;, that causes the stack trace to be re-created to point at your throw ex line and you won't know which line of code the real exception was thrown from.

Upvotes: 0

Related Questions