0

我在此处的 Redhawk 前端接口文档中看到，如果相应的操作不成功，调用 allocateCapacity() 和 deallocateCapacity() 意味着抛出某些异常。然而，Redhawk 1.9 中的当前代码生成（以及从它的外观来看，在当前开发中）表明开发人员应该使用在分配属性上调用 setAllocator() 的范式和分配器对象。分配器接口如下：

public interface Allocator<E> {
    public boolean allocate(E capacity);
    public void deallocate(E capacity);
}

这些方法不会抛出（检查的）异常类型 InvalidCapacity 和 InvalidState。我期望能够在我的 allocate() 和 deallocate 的实现期间抛出这些调谐器分配结构属性，并让它们传播到 allocateCapacity() deallocateCapacity() 调用，但是分配器接口上缺少 @throws 语句阻止我这样做。

我的问题是：

  1. 我认为开发人员应该使用 setAllocator() 方法是否正确？
  2. 如果是这样，有没有办法在分配器实现中抛出这些检查的异常，或者我们不鼓励在非生成的代码中抛出这些异常？
    2.a. 如果不鼓励抛出这些，是否有任何标准方法表明释放失败？
  3. 如果没有，我们应该如何实施分配？在设备类中直接覆盖 allocateCapacity() 和 deallocateCapacity() 似乎是一种糟糕的方法。

我在 RHEL 5 上使用 Redhawk 1.9.0 进行开发。

4

1 回答 1

1

是的，通常分配器接口是实现分配的首选方法。在大多数情况下，Device 基类将为您处理引发 InvalidState 和 InvalidCapacity 异常。但是，它假定通用设备，并且在 FRONTEND 规范中有几个地方打算抛出无法在基类级别检查的异常，例如分配 ID 是否有效。不幸的是，由于 InvalidState 和 InvalidCapacity 是检查方法，因此无法直接通过 Allocator 接口执行此操作。

围绕这个限制，我可以想到两种方法：

  1. 实现你自己的 allocateCapacity() 和 deallocateCapacity()，这意味着你必须重新实现基类的所有功能
  2. 在 allocate() 和 deallocate() 中抛出未经检查的异常
    • allocate() 将 IllegalArgumentException 转换为 CF.Device.InvalidCapacity
    • deallocate() 将 ArithmeticException 和 IllegalArgumentException 转换为 CF.Device.InvalidCapacity

在 1.9 之前，无论如何您都必须执行 #1，所以这不是一个坏方法。#2 的问题在于它是一个 hack，使用 IllegalArgumentException 会丢失异常的消息。

于 2014-07-21T13:17:49.457 回答