Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
| Dev |
|
| QA |
|
| Priority | Major |
| Complexity | Unknown |
| Component | App - FluidShell |
| Version | 12.0 |
The error catching mechanism has changed in FluidShell v2, such that only a short message is displayed in SQL Shell window, while the full stack trace can be seen on the datastudio.log file or if the Error Log window is already open and thus capturing is active. This is a good change, as it keeps minimal error information in the FluidShell window.
But in batch mode this behavior is not helpful. Sometimes the error is too short (see issue #6849 ) and the full stack trace would help if sent to developers for further investigation. But in batch mode there is currently no way to retrieve the error stack trace from end-users, as it is not printed on console (Bash etc) nor in the datastudio.log file. I guess the error stream is not properly initialized / handled in this mode and thus the error stack trace is lost.
In RunFluidShell, the logger is initialized to write messages to console.
The reason that stack trace is logged in interactive mode but not batch mode is because those stack traces are logged through Editor.appendError(Throwable). When running in batch mode, there is no Editor instance, hence, stack trace is not logged.
I looked up callers of Editor.appendError(Throwable) and made changes there, so that if Editor is null then Throwable is sent to logger (in some cases). There are might some other scenarios that stack trace may not be logged in batch mode, we need to fix them case by case.
Since the logger defined in RunFluidShell writes log to console, so you will see both 'short error message' and 'stack trace' displayed in console. Below is a simple test case:
test.sh
connect -v SERVER_NAME # assuming SERVER_NAME is a valid file name
disconnect
declare DATABASE=6852-xyz # assuming database 6852-xyz does not exist
reconnect # would fail
reconnect -v # should go through
disconnect
declare DATABASE=6852-abc # assuming database 6852-abc does not exist
reconnect # would fail
12.0.0-dev-130. Will test whether stacktrace is logged for all commands and log as separate issue.
12.0.0-dev-130. Will test whether stacktrace is logged for all commands and log as separate issue.
Issue #6852 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| Fixed Build trunk/27300 |
| No time estimate |
In RunFluidShell, the logger is initialized to write messages to console.
The reason that stack trace is logged in interactive mode but not batch mode is because those stack traces are logged through Editor.appendError(Throwable). When running in batch mode, there is no Editor instance, hence, stack trace is not logged.
I looked up callers of Editor.appendError(Throwable) and made changes there, so that if Editor is null then Throwable is sent to logger (in some cases). There are might some other scenarios that stack trace may not be logged in batch mode, we need to fix them case by case.
Since the logger defined in RunFluidShell writes log to console, so you will see both 'short error message' and 'stack trace' displayed in console. Below is a simple test case:
test.sh
connect -v SERVER_NAME # assuming SERVER_NAME is a valid file name
disconnect
declare DATABASE=6852-xyz # assuming database 6852-xyz does not exist
reconnect # would fail
reconnect -v # should go through
disconnect
declare DATABASE=6852-abc # assuming database 6852-abc does not exist
reconnect # would fail