pentaho/pentaho-kettle · error · KettleFileException
TextFileInput.Log.Error.ExceptionReadingLine
TextFileInput.Log.Error.ExceptionReadingLine
Error message
TextFileInput.Log.Error.ExceptionReadingLine
What it means
getLine() wraps any unexpected Exception thrown while reading characters from the file into a KettleFileException with this message — but only when no partial line has been accumulated (line.length()==0). If some characters were already read, they are returned as the line instead. The original exception is attached as the cause.
Solutions
- Check the attached cause (e.toString() is embedded in the message) to identify the real I/O or charset problem.
- Verify the step's Encoding setting matches the file's actual encoding (UTF-8 vs ISO-8859-1 etc.).
- Re-check the file exists and is readable/stable on disk or the network location during the transformation run.
- If remote (SFTP/VFS), test connectivity and copy the file locally before processing.
Example fix
// before: Encoding=UTF-8 but file is ISO-8859-1 with invalid byte sequences // after: set the Text File Input step Encoding to ISO-8859-1 // (Content tab -> Encoding -> ISO-8859-1) to match the source file
Defensive patterns
Strategy: try-catch
Validate before calling
// Verify the file decodes cleanly with the configured charset before processing Charset cs = Charset.forName(encoding); new String(Files.readAllBytes(path), cs); // throws MalformedInputException-related errors early CharsetDecoder strict = cs.newDecoder(); strict.decode(ByteBuffer.wrap(Files.readAllBytes(path)));
Try / catch
try {
line = getLine();
} catch (KettleFileException e) {
Throwable cause = e.getCause();
logError("Line read failed: " + cause, e);
if (isRecoverableIO(cause)) { retryWithBackoff(); } else { failStep(); }
} Prevention
- Always set Encoding explicitly to match the source file
- Validate file decodability before the transformation runs
- Keep files local/stable during processing; avoid reading from flaky network shares
When it happens
Trigger: Any I/O or decoding failure during reader.read() in getLine() (e.g. character-decoding errors, stream closed, underlying file system error) at the very start of a line.
Common situations: Encoding mismatches (file bytes invalid for the chosen character set), files removed or truncated mid-read on network shares, VFS connection drops while reading remote files.
Understand the failure class
Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.
Related errors
- TextFileInput.Log.Error.ErrorConvertingLineText
- TextFileInput.Log.SingleLineFound
- Already closed
- Already closed
- An error occurred writing data to the MonetDB API (MAPI)…
AI-assisted analysis of pentaho/pentaho-kettle@f3058517a1 (2026-09-13).
Data as JSON: /api/errors/7b31fdfa7f7cc801.
Report an issue: GitHub.
Appendix: source
Thrown at engine/src/main/java/org/pentaho/di/trans/steps/textfileinput/TextFileInput.java:153
c = reader.read();
if ( encodingType.isLinefeed( c ) ) {
return line.toString();
} else if ( !encodingType.isReturn( c ) ) {
if ( c >= 0 ) {
line.append( (char) c );
}
}
}
break;
default:
break;
}
} catch ( KettleFileException e ) {
throw e;
} catch ( Exception e ) {
if ( line.length() == 0 ) {
throw new KettleFileException( BaseMessages.getString( PKG, "TextFileInput.Log.Error.ExceptionReadingLine", e
.toString() ), e );
}
return line.toString();
}
if ( line.length() > 0 ) {
return line.toString();
}
return null;
}
@Deprecated
public static final String[] guessStringsFromLine( LogChannelInterface log, String line, TextFileInputMeta inf,
String delimiter ) throws KettleException {
return guessStringsFromLine( new Variables(), log, line, inf, delimiter, StringUtil.substituteHex( inf
.getEnclosure() ), StringUtil.substituteHex( inf.getEscapeCharacter() ) );
}
View on GitHub (pinned to f3058517a1)