Package jline.io

Class LineException

java.lang.Object
java.lang.Throwable
java.lang.Exception
java.lang.RuntimeException
jline.io.LineException
All Implemented Interfaces:
Serializable
public class LineException extends RuntimeException
The exception every deliberate LINE diagnostic throws.

It carries NO stack trace of its own. A line_error is a message LINE wrote on purpose and its text already names the caller, so the frames between the throw and whatever the user called (runAnalyzerChecks -> runAnalyzer -> getAvg -> getAvgTable -> ...) are noise: printing them buries a one-sentence refusal such as "finite station capacity at station 'Queue2' is not supported by SolverNC" under a screen of internal frames the user neither chose nor can act on. The JVM's default handler, printStackTrace() and MATLAB's lang='java' bridge then all report the message alone. This mirrors the empty-stack throw of matlab/src/io/line_error.m.

The suppression is decided ONCE, when the exception is constructed, from GlobalConstants.Verbose: at VerboseLevel.DEBUG the trace is writable and the full chain comes back, which is what a developer wants. Genuine JVM faults (IndexOutOfBoundsException, NullPointerException) never come through here and are untouched.

A CAUSE KEEPS ITS OWN TRACE. Only this wrapper's frames are dropped, so the "Caused by:" block of a re-reported failure still points at the line that actually broke -- the whole reason line_error(caller, msg, cause) exists.

It extends RuntimeException, which is what line_error threw before, so every existing catch (RuntimeException) still catches it.

See Also:

  • Constructor Details

    • LineException

      public LineException(String message)
      Parameters:
      message - the already-formatted diagnostic

    • LineException

      public LineException(String message, Throwable cause)
      Parameters:
      message - the already-formatted diagnostic
      cause - the failure being re-reported, or null