* However, we can't usually write {@code throw t;} when {@code t} has a static type of {@link
   * Throwable}. But we <i>can</i> write {@code sneakyThrow(t);}.
   *
   * <p>We sometimes also use {@code sneakyThrow} for testing how our code responds to
   * sneaky checked exception.
   *
   * @return never; this method declares a return type of {@link Error} only so that callers can

 * tree, including share type and capabilities.
 *
 * @author mbechler
 */
public class Smb2TreeConnectResponse extends ServerMessageBlock2Response implements TreeConnectResponse {

    /**
     * Share type constant for disk shares (file shares).
     */
    public static final byte SMB2_SHARE_TYPE_DISK = 0x1;
    /**
     * Share type constant for named pipe shares (IPC).
     */

            if (executionEvent.getType() == ExecutionEvent.Type.SessionEnded) {
                allHandlers.clear();
            }
        }
    }

    public ArtifactHandler getArtifactHandler(String type) {
        requireNonNull(type, "null type");
        ArtifactHandler handler = allHandlers.get(type);
        if (handler == null) {
            handler = artifactHandlers.get(type);
            if (handler == null) {

    }

    /**
     * Gets a role type by its ID.
     * @param id The ID of the role type.
     * @return An optional entity of the role type.
     */
    public OptionalEntity<RoleType> getRoleType(final String id) {
        return roleTypeBhv.selectByPK(id);
    }

    /**
     * Stores a role type.
     * @param roleType The role type to store.
     */
    public void store(final RoleType roleType) {

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code