View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0017346||FPC||RTL||public||2010-09-04 15:17||2019-12-05 16:04|
|Reporter||Benito van der Zander||Assigned To||Michael Van Canneyt|
|Target Version||3.2.0||Fixed in Version||3.0.0|
|Summary||0017346: unhandled exceptions on stdout|
|Description||Unhandled exceptions are written to stdout, but I think they should be written to stderr.|
Stderr is the standard on unix for errors, and if you redirect stdout to a file, you don't get the error messages.
Procedure CatchUnhandledException (Obj : TObject; Addr: Pointer; FrameCount: Longint; Frames: PPointer);[public,alias:'FPC_BREAK_UNHANDLED_EXCEPTION'];
Message : String;
i : longint;
hstdout : ^text;
Writeln(hstdout^,'An unhandled exception occurred at $',HexStr(PtrUInt(Addr),sizeof(PtrUInt)*2),' :');
if Obj is exception then
|Fixed in Revision||30140.|
||(I agree in so far that it at least should be possible to change to stderr)|
since (at least) 9 years there are contrary opinions to the question,
whether r.e.m. (runtime error messages) from programs
(mainly, but not only: console programs)
that are generated by freepascal,
should go to stdout or stderr.
look at the following three cited issues, with comments from me:
> 0005620 descr: In Linux it would be nice to redirect the error
> 0005620 descr: messages to the stderr instead of stdout.
not only in linux. also in other unixes, msdos, mswin.
> 0005620 notes: Added option -vz
> 0005620 closed + fixed, 2005, v.1.9.6
very good. but, why did this option disappear later?
- - - -
> 0012996 notes: (Maebe) All run time error handling in the RTL uses stdout.
assert-messages go to stderr (without sysutils).
why is the handling different?
> 0012996 notes: (Maebe) Changing this to stderr would break
> 0012996 notes: backwards compatibility for little gain.
> 0012996 closed + won't fix, 2009, v.2.2.2
'compatibility': why do you not offer both alternatives?
'little gain': (see below)
- - - -
> 0017346 notes: (van de Voort) I agree in so far that it at
> 0017346 notes: least should be possible to change to stderr
> 0017346 new + open + tweak, 2010, v.2.4.0
very good. but, why has this idea not been realized in the last 4 years?
- - - -
of course a human can differentiate between r.e.m. and actual output
in the output of a freepascal-program.
but how can the differentiation happen,
if this output is processed by a (other) program?
an important example are (unnamed) pipelines
in command-lines of the form
prog1 | prog2 | ... | progN .
in such cases freepascal-programs are unusable (as long as
they do not differentiate between r.e.m. and actual output).
therefore I can not understand Mr.Maebe's 'little gain' (0012996).
I hope I have shown convincingly the importance of the
request 'r.e.m. --> stderr',
and that the idea of Mr.van de Voort (0017346) will soon be realized.
Bug report 0005620 was interpreted differently from what the submitter probably intended. The "fix" was an option (-vz) to let the compiler write its error messages to stderr. It didn't change anything to how compiled programs behave. That option still behaves the same today as it did back then.
|Any news on this? Getting error output to stderr sounds like a sensible thing to do, especially useful when running FPC programs as external processes (*cough* as fpcup does *cough*)|
is there something new?
(think of usability of fpc-prog's (mainly: non-gui) in pipelines.
but I recur. see note 0073968.)
Since the original "fix" doesn't fix pipe behavior.
The request was to write errors (and or exceptions) to stderr.
Exceptions should imo be handled in code and in isolation from pipe in/out, but errors should be written to stderr.
I changed the default to write unhandled exceptions to StdErr.
The behaviour is controlled by a boolean in SysUtils:
Which is by default set to true. Those that want it can revert to the old behaviour by setting this variable to False.
|2010-09-04 15:17||Benito van der Zander||New Issue|
|2010-09-04 15:28||Marco van de Voort||Note Added: 0040801|
|2010-09-04 15:35||Jonas Maebe||FPCOldBugId||=> 0|
|2010-09-04 15:35||Jonas Maebe||Severity||major => tweak|
|2014-03-23 19:23||Jonas Maebe||Relationship added||has duplicate 0025906|
|2014-03-25 19:18||hapr35||Note Added: 0073968|
|2014-03-25 21:44||Jonas Maebe||Note Added: 0073974|
|2014-03-25 21:45||Jonas Maebe||Note Edited: 0073974||View Revisions|
||Tag Attached: output|
||Tag Attached: Exception|
||Note Added: 0077580|
|2014-10-16 13:58||Michael Van Canneyt||Assigned To||=> Michael Van Canneyt|
|2014-10-16 13:58||Michael Van Canneyt||Status||new => assigned|
|2015-02-15 21:36||hapr35||Note Added: 0081115|
|2015-02-16 18:49||Thaddy de Koning||Note Added: 0081140|
|2015-02-16 18:51||Thaddy de Koning||Note Edited: 0081140||View Revisions|
|2015-03-08 10:49||Michael Van Canneyt||Fixed in Revision||=> 30140.|
|2015-03-08 10:49||Michael Van Canneyt||Note Added: 0081719|
|2015-03-08 10:49||Michael Van Canneyt||Status||assigned => resolved|
|2015-03-08 10:49||Michael Van Canneyt||Fixed in Version||=> 3.1.1|
|2015-03-08 10:49||Michael Van Canneyt||Resolution||open => fixed|
|2015-03-08 10:49||Michael Van Canneyt||Target Version||=> 4.0.0|
|2015-08-30 22:47||Joost van der Sluis||Fixed in Version||3.1.1 => 3.0.1|
|2019-12-05 16:04||Michael Van Canneyt||Build||2.4.0-2 [2010/02/20] => 2.4.0-2 [2010/02/20]|
|2019-12-05 16:04||Michael Van Canneyt||Target Version||4.0.0 => 3.2.0|
|2019-12-05 16:04||Michael Van Canneyt||FPCTarget||=> -|