|
1
|
This panic is raised by the Set() member function of
CAsyncCallBack, if this active object is already active when the
function is called.
|
|
2
|
This panic is raised in debug builds only.
This panic is raised by the Call() member function of
CAsyncOneShot if the active object has not already been added to
the active scheduler.
|
|
3
|
This panic is raised during construction of a dynamic buffer (a
CBufFlat or a CBufSeg) when the value
of the granularity passed to the constructors is negative.
|
|
4
|
This panic is raised when reading from a dynamic buffer (a
CBufFlat or a CBufSeg) using the
Read() member function. It is caused by attempting to read beyond
the end of the buffer.
|
|
5
|
This panic is raised when writing to a dynamic buffer (a
CBufFlat or a CBufSeg) using the
Write() member function. It is caused by attempting to write
beyond the end of the buffer.
|
|
6
|
This panic is raised when reading from a dynamic buffer (a
CBufFlat or a CBufSeg) using the
Read() member function. It is caused by specifying a negative
length for the amount of data to be read
|
|
7
|
This panic is raised when writing to a dynamic buffer (a
CBufFlat or a CBufSeg) using the
Write() member function. It is caused by specifying a negative
length for the amount of data to be written.
|
|
8
|
This panic is raised when inserting data into a dynamic buffer (a
CBufFlat or a CBufSeg) using the
InsertL() member function or when inserting an uninitialized
region into the dynamic buffer using the ExpandL() member
function. It is caused by passing a negative length value to these functions.
|
|
9
|
This panic is raised when inserting data into a dynamic buffer (a
CBufFlat or a CBufSeg) using the
InsertL() member function. It is caused when the variant of
InsertL() which takes a pointer to TAny, is passed a
NULL pointer value.
|
|
10
|
This panic is raised when specifying the minimum amount of space
which a flat dynamic buffer (a CBufFlat) should occupy
using the SetReserveL() member function. It is caused when the
size value passed to the function is negative.
|
|
11
|
This panic is raised when specifying the minimum amount of space
which a flat dynamic buffer (a CBufFlat) should occupy
using the SetReserveL() member function. It is caused when the
size value passed to the function is less than the current size of the buffer.
|
|
12
|
This panic is raised by the Delete(),
Ptr(), BackPtr() member functions of a flat dynamic
buffer (a CBufFlat); the panic can also be raised by
InsertL() and ExpandL(). It is caused when the
position value passed to these functions is either negative or represents a
position beyond the end of the current buffer.
|
|
13
|
This panic is raised by the Delete() member function
of a flat dynamic buffer (a CBufFlat). It is caused when
the combination of position and length values passed to the function implies an
attempt to delete data beyond the end of the flat buffer.
|
|
14
|
This panic is raised by the Delete(),
Ptr(), BackPtr() member functions of a segmented
dynamic buffer (a CBufSeg); the panic can also be raised
by InsertL() and ExpandL(). It is caused when the
position value passed to these functions is either negative or represents a
position beyond the end of the current buffer.
|
|
15
|
This panic is raised by the Delete() member function of a segmented
dynamic buffer (a CBufSeg). It is caused when the
combination of position and length values passed to the function implies an
attempt to delete data beyond the end of the segmented buffer.
|
|
16
|
This panic is raised in debug builds only.
This panic is raised by the InsertL(),
Delete(), Ptr() and BackPtr() member
functions as implemented for segmented buffers (CBufSeg),
when the offset within a segment, where data is to be inserted or removed, is
greater than the buffer granularity.
|
|
17
|
This panic is raised by the constructors of arrays of fixed length
objects as represented, for example, by the classes
CArrayFixFlat, CArrayFixSeg and
CArrayFixFlat<TAny>. It is caused when the record
length is either negative or zero.
The record length is either explicitly specified as in the case of
the CArrayFixFlat<TAny> class or is implied by the
length of the template class as in the case of the
CArrayFixFlat class.
|
|
18
|
This panic is raised by the constructors of arrays of fixed length
objects as represented, for example, by the classes:
CArrayFixFlat and CArrayFixSeg. It is
caused when the granularity passed to the constructors is either negative or
zero.
|
|
19
|
This panic is raised by the constructors of arrays of variable
length objects as represented, for example, by the classes:
CArrayVarFlat and CArrayVarSeg. It is
caused when the granularity passed to the constructors is either negative or
zero.
|
|
20
|
This panic is raised by the constructors of packed arrays as
represented, for example, by the class CArrayPakFlat. It
is caused when the granularity passed to the constructors is either negative or
zero.
|
|
21
|
This panic is raised by any operation which accesses an element of
an array by explicit reference to an index number, for example, the
Delete(), InsertL() and At() member
functions or the operator Operator[]. It is caused by specifying
an index value which is either negative or is greater than or equal to the
number of objects currently within the array.
|
|
22
|
This panic is raised when deleting contiguous elements from an
array of fixed length objects (derived from CArrayFixBase)
using the Delete() member function. It is caused by specifying the
number of contiguous elements as a zero or negative value.
|
|
23
|
This panic is raised when inserting contiguous elements into an
array of fixed length objects (derived from CArrayFixBase)
using the InsertL() member function. It is caused by specifying
the number of contiguous elements as a zero or negative value.
|
|
24
|
This panic is raised when resizing an array of fixed length objects
(derived from CArrayFixBase) using the
ResizeL() member function. It is caused by specifying the number
of contiguous elements as a zero or negative value.
|
|
25
|
This panic is raised when deleting contiguous elements from an
array of variable length objects (derived from
CArrayVarBase) using the Delete() member
function. It is caused by specifying the number of contiguous elements as a
zero or negative value.
|
|
26
|
This panic is raised when deleting contiguous elements from a
packed array (derived from CArrayPakBase) using the
Delete() member function. It is caused by specifying the number of
contiguous elements as a zero or negative value.
|
|
27
|
This panic is raised when reserving space in flat arrays of fixed
length objects, (the
CArrayFixFlat,CArrayFixFlat<TAny>
and CArrayPtrFlat classes ) using the
SetReserveL() member function. It is caused by specifying the
number of elements, for which space is to be reserved, as less than the current
number of elements in the array.
|
|
28
|
This panic is raised when inserting or appending replicated
elements to the arrays of fixed length objects
CArrayFixFlat and CArrayFixSeg using
the InsertL() or AppendL() functions. It is caused by
specifying the number of replicas as negative or zero.
|
|
29
|
This panic is raised when deleting elements from a fixed length,
variable length or packed array (derived from
CArrayFixBase, CArrayVarBase and
CArrayPakBase) using the Delete() function.
It is caused when the specification of the position of the first element to be
deleted and the number of contiguous elements to be deleted refers to elements
which are outside the bounds of the array.
|
|
30
|
This panic is raised when inserting into, appending onto, expanding
or extending a variable length array or a packed array (i.e. arrays derived
from CArrayVar or CArrayPak) using
the InsertL(), AppendL(), ExpandL() or
ExtendL() functions respectively. It is caused by specifying the
length of the element as a negative value.
|
|
33
|
This panic is raised by the destructor of a
CObject. It is caused, if an attempt is made to delete the
CObject when the reference count is not zero.
|
|
34
|
This panic is raised by the Close() member function of
a CObject. It is caused, if the reference count is
negative.
|
|
35
|
This panic is raised by the Remove() member function
of an object container, a CObjectCon. It is caused when
the CObject to be removed from the container is not
contained by the container.
|
|
36
|
This panic is raised by the Remove() member function
of a container index, a CObjectConIx. It is caused when
the object container, a CObjectCon, to be removed from the
index is not contained by the index.
|
|
37
|
This panic is raised by the Remove() member function
of an object index, a CObjectIx. It is caused when the
handle passed to the Remove() function does not represent a
CObject known to the object index.
|
|
38
|
This panic is raised by the At(),
FindByName() and FindByFullName() member functions of
an object container, a CObjectCon. It is caused when the
unique ID as derived from the handle is not the same as the unique ID held by
the object container.
|
|
39
|
This panic is raised by the At() member function of an
object container, a CObjectCon. It is caused when the
index represented by the handle is outside the permitted range. In effect, the
handle is bad.
|
|
40
|
This panic is raised by the destructor of an active object, a
CActive. It is caused by an attempt to delete the active
object while it still has a request outstanding.
|
|
41
|
This panic is raised by the Add() member function of
an active scheduler, a CActiveScheduler. It is caused by
an attempt to add an active object to the active scheduler when it has already
been added to the active scheduler
|
|
42
|
This panic is raised by the SetActive() member
function of an active object, a CActive. It is caused by
an attempt to flag the active object as active when it is already active, i.e.
a request is still outstanding.
|
|
43
|
This panic is raised by the Install() member function
of an active scheduler, a CActiveScheduler. It is caused
by attempting to install this active scheduler as the current active scheduler
when there is already a current active scheduler; i.e. an active scheduler has
already been installed.
|
|
44
|
This panic is raised by calls to the Start(),
Stop() and Add() member functions of an active
scheduler, a CActiveScheduler when the thread does not
have an installed active scheduler.
|
|
45
|
This panic is raised by the Stop() member function of
an active scheduler, a CActiveScheduler. Calling
Stop() terminates the wait loop started by the most recent call to
Start(). The panic is caused by a call to Stop()
which is not matched by a corresponding call to Start().
|
|
46
|
This panic is raised by an active scheduler, a
CActiveScheduler. It is caused by a stray signal.
|
|
47
|
This panic is raised by the Error() virtual member
function of an active scheduler, a CActiveScheduler. This
function is called when an active object’s RunL() function leaves.
Applications always replace the Error() function in a class
derived from CActiveScheduler; the default behaviour provided by
CActiveScheduler raises this panic.
|
|
48
|
This panic is raised by the Add() member function of
an active scheduler, a CActiveScheduler, when a NULL
pointer is passed to the function.
|
|
49
|
This panic is raised by the SetActive() and
Deque() member functions of an active object, a
CActive. It is raised if the active object has not been
added to the active scheduler.
|
|
50
|
This panic is raised by the SetPriority() member
function of an active object, a CActive. It is caused by
an attempt to change the priority of the active object while it is active, i.e.
while a request is outstanding).
|
|
51
|
This panic is raised by the At(), After()
and Lock() member functions of the CTimer
active object. It is caused by an attempt to request a timer event when the
CTimer active object has not been added to the active scheduler.
|
|
52
|
This panic is raised by the Start() member function of
the periodic timer active object, a CPeriodic, when a
negative time interval is passed to the function.
|
|
53
|
This panic is raised by the Start() member function of
the periodic timer active object, a CPeriodic, when a
negative delay time interval is passed to the function.
|
|
54
|
This panic is raised by the RunL() member function of
the CServer active object base class responsible for
handling asynchronous requests from a client thread when the client passes a
negative function code in RMessage. The only negative
values permitted are RMessage::EConnect and RMessage::EDisConnect.
|
|
55
|
This panic is raised by the Start() member function of
the CServer active object base class responsible for
handling asynchronous requests from a client thread. It is caused by the server
having no name.
|
|
56
|
This panic is raised by the New() and
NewL() member functions of CBitMapAllocator when a
negative or zero size is passed to them.
|
|
57
|
This panic is raised by the Free(TInt aPos) member
function of CBitMapAllocator when a position value is passed which
is out of bounds.
|
|
58
|
This panic is raised by the IsFree(TInt aPos) member
function of CBitMapAllocator when a position value is passed which
is out of bounds.
|
|
59
|
This panic is raised by the AllocFromTopFrom(TInt
aPos) member function of CBitMapAllocator when a position
value is passed which is out of bounds.
|
|
62
|
This panic is raised by the AllocAt() member function
of CBitMapAllocator when the implied position has already been
allocated.
|
|
63
|
This panic is raised as a result of a call to the
Pop() and PopAndDestroy() static member functions of
the CleanupStack class. The panic occurs when TRAPs have
been nested and an attempt is made to pop too many items from the cleanup stack
for the current nest level.
|
|
64
|
This panic is raised as a result of a call to the
Pop() and PopAndDestroy() static member functions of
the CleanupStack class. The panic occurs when attempt is
made to pop more items from the cleanup stack than are on the cleanup stack.
|
|
65
|
The panic is raised as a result of a call to the Pop()
and PopAndDestroy() static member functions of the
CleanupStack class. The panic occurs when an attempt is made to
pop more items from the cleanup stack than are on the cleanup stack.
|
|
66
|
This panic is raised if an attempt is being made to insert a
cleanup item into a position on the cleanup stack reserved for marking the
current TRAP nest level. In practice this
error occurs if the call to CleanupStack::PushL() happens
when there has been no call to TRAP().
|
|
67
|
This panic is raised when building a TCleanupStackItem
which is to be added to the cleanup stack. The building of the
TCleanupStackItem needs a TCleanupItem and
this has been constructed with a NULL cleanup operation (a
TCleanupOperation).
|
|
68
|
This panic is raised if there are no free slots available on the
cleanup stack to insert a cleanup item
|
|
69
|
This panic is raised if no trap handler has been installed. In
practice, this occurs if CTrapCleanup::New()
has not been called before using the cleanup stack.
|
|
70
|
This panic is raised as a result of a call to the versions of the
Pop() and PopAndDestroy() static member functions of
the CleanupStack class which take an explicit count of the
items to be popped. The panic is caused by passing a negative value for the
number of items to be popped.
|
|
71
|
This panic is raised when TRAPs have been nested and an attempt is made to
exit from a TRAP nest level before all the
cleanup items belonging to that level have been popped off the cleanup stack.
There must be the same number of items on the cleanup stack on
entering a TRAP harness as there is on
exiting. In other words, anything that is pushed onto the cleanup stack inside
a TRAP harness must be popped off before
leaving the harness.
For example, the following code avoids this panic when
FooLC() does not leave, by explicitly popping pointer
before the end of the harness:
TRAPD(error, pointer = FooLC(); CleanupStack::Pop(pointer));
See also How to use TRAP.
|
|
72
|
This panic is raised by the constructor of the circular buffer base
class, a CCirBufBase, when the size value passed is zero
or negative.
|
|
73
|
This panic is raised by a call to the SetLengthL()
member function of of the circular buffer base class, a
CCirBufBase, by passing a length value which is zero or
negative.
|
|
74
|
This panic is raised by a call to the Add() member
function of a circular buffer, a CCirBuf when the pointer
to the item to be added is NULL.
|
|
75
|
This panic is raised by a call to the Add() member
function of a circular buffer, a CCirBuf when the number
of items to be added is zero or negative
|
|
76
|
This panic is raised by a call to the Remove() member
function of a circular buffer, a CCirBuf when the number
of items to be removed is zero or negative.
|
|
89
|
Introduced in 6.0: This panic is raised by call to the
Replace() member function of CActiveScheduler
when the replacement active scheduler is the same as the existing active
scheduler.
|
|
90
|
Introduced in 6.0: The panic is raised as a result of a call to the
Pop() and PopAndDestroy() static member functions of
the CleanupStack class. The panic occurs when an the item to be
popped is not the expected item.
|
|
91
|
This panic is raised by
CActiveSchedulerWait::Start() when the
CActiveSchedulerWait object has already been started.
|
|
92
|
This panic is raised by
CActiveSchedulerWait::AsyncStop() and
CActiveSchedulerWait::CanStopNow() when the
CActiveSchedulerWait object has not been started.
|
|
93
|
This panic is raised during construction of a
CAsyncOneShot if the attempt to open a handle to the
current thread fails.
|
|
94
|
Not used.
|
|
95
|
This panic is raised on calls to the default implementations of
functions: CPolicyServer::CustomSecurityCheckL() and
CPolicyServer::CustomFailureActionL().
The class CPolicyServer is intended to be
derived from, and these functions in particular need to be re-implemented in a
derived class. This panic is a symptom of a failure to provide a derived class.
|
|
96
|
This panic is raised in debug builds only.
It is raised by the protected CPolicyServer
constructor, if the first element pointed to by the iRanges member
of the TPolicy
aPolicy parameter does not
have a value of 0; i.e. if aPolicy's
TPolicy::iRanges[0] is not 0.
|
|
97
|
This panic is raised in debug builds only.
It is raised by the protected CPolicyServer
constructor, if the value of each element of the iRanges member of
the TPolicy
aPolicy parameter is not greater
than the value of the previous element.
See also TPolicy::iRanges.
|
|
98
|
This panic is raised in debug builds only.
It is raised by the protected CPolicyServer
constructor, if the value of every element in the iElementsIndex
member of the TPolicy
aPolicy parameter is
not valid.
Elements of iElementsIndex are invalid if their values
are either:
or
See also TPolicy::iElementsIndex and
CPolicyServer::TSpecialCase.
|
|
99
|
This panic is raised in debug builds only.
It is raised by the protected CPolicyServer
constructor, if the value of the iOnConnect member of the
TPolicy
aPolicy parameter is not valid.
The iOnConnect member is invalid if its value is
either:
or
See also TPolicy::iOnConnect and
CPolicyServer::TSpecialCase.
|
|
100
|
This panic is raised if CPolicyServer::iPolicy
is found to be invalid for some unknown reason.
If you run the server in debug mode, it is likely that the server
will panic with one of the panic codes in the range 96 to 99 inclusive. These
are described above.
See CPolicyServer for information about what
constitutes a valid policy.
|
|
101
|
This panic is raised when the value returned by the
CPolicyServer::CustomSecurityCheckL() and
CPolicyServer::CustomFailureActionL() functions is
invalid.
The CPolicyServer::TCustomResult enum defines
the valid set of return values.
|
|
102
|
This panic is raised in debug builds only.
It is raised by the protected CPolicyServer
constructor, if the value of the iRangeCount member of the
TPolicy
aPolicy parameter is not greater than
0. A value of 0 implies that no policies have been passed to the policy server.
It is a requirement that at least one policy be passed to the policy server.
|
|
103
|
This panic is raised by the policy server framework if a message
fails a policy check, whether custom or not.
|
|
104
|
This panic is raised in debug builds only.
It is raised by a number of CObjectIx member
functions if the object's data becomes inconsistent.
|
![[Index]](../../../a_stock/btn_index_wt.gif){kind=small}
![[Spacer]](../../../a_stock/btn_spacer.gif){kind=small}
![[Previous]](../../../a_stock/btn_prev_wt.gif){kind=small}
![[Next]](../../../a_stock/btn_next_wt.gif){kind=small}
![[Previous]](../../../a_stock/btn_prev.gif){kind=small}
![[Top]](../../../a_stock/btn_top.gif)
![[Next]](../../../a_stock/btn_next.gif){kind=small}