If the program wants to handle this exception in particular, it should catch ContextNotEmptyException explicitly before attempting to catch NamingException. For example, after catching ContextNotEmptyException, the program might try to remove the contents of the context before reattempting the destroy.
Synchronization and serialization issues that apply to NamingException apply directly here.
Context#destroySubcontext
| Modifier and Type | Field and Description |
|---|---|
| private static final long | serialVersionUID
Use serialVersionUID from JNDI 1.1.1 for interoperability
|
| Access | Constructor and Description |
|---|---|
| public | ContextNotEmptyException(String
Possibly null string containing
additional detail about this exception. explanation)Constructs a new instance of ContextNotEmptyException using an explanation. |
| public | ContextNotEmptyException()
Constructs a new instance of ContextNotEmptyException with all name resolution fields and explanation initialized to null. |
| serialVersionUID | back to summary |
|---|---|
| private static final long serialVersionUID Hides javax. Use serialVersionUID from JNDI 1.1.1 for interoperability | |
| ContextNotEmptyException | back to summary |
|---|---|
| public ContextNotEmptyException(String explanation) Constructs a new instance of ContextNotEmptyException using an explanation. All other fields default to null.
| |
| ContextNotEmptyException | back to summary |
|---|---|
| public ContextNotEmptyException() Constructs a new instance of ContextNotEmptyException with all name resolution fields and explanation initialized to null. | |