What happened?
amber/src/main/scala/org/apache/texera/amber/engine/architecture/messaginglayer/AmberFIFOChannel.scala::getPortId does this.portId.get on an Option[PortIdentity] that defaults to None. Calling getPortId before setPortId therefore throws a bare NoSuchElementException with no contextual message — quite different from a guard-and-raise (require(...), assert(...)) that would point the caller at the missing setup step.
portId is also untyped at the API level (the public getter declares PortIdentity, not Option[PortIdentity]), so callers cannot pattern-match safely; their only options today are blind .get access or wrapping in a try/catch.
How to reproduce?
import org.apache.texera.amber.core.virtualidentity.{ActorVirtualIdentity, ChannelIdentity}
import org.apache.texera.amber.engine.architecture.messaginglayer.AmberFIFOChannel
val ch = new AmberFIFOChannel(
ChannelIdentity(ActorVirtualIdentity("from"), ActorVirtualIdentity("to"), isControl = false)
)
ch.getPortId
// java.util.NoSuchElementException: None.getVersion
1.1.0-incubating (Pre-release/Master)
What happened?
amber/src/main/scala/org/apache/texera/amber/engine/architecture/messaginglayer/AmberFIFOChannel.scala::getPortIddoesthis.portId.geton anOption[PortIdentity]that defaults toNone. CallinggetPortIdbeforesetPortIdtherefore throws a bareNoSuchElementExceptionwith no contextual message — quite different from a guard-and-raise (require(...),assert(...)) that would point the caller at the missing setup step.portIdis also untyped at the API level (the public getter declaresPortIdentity, notOption[PortIdentity]), so callers cannot pattern-match safely; their only options today are blind.getaccess or wrapping in a try/catch.How to reproduce?
Version
1.1.0-incubating (Pre-release/Master)