Intercept os.Exit

[Archos]

Is there any way to intercept calls to os.Exit ?

My library has sentences to defer so they could not be run if some
developer use os.Exit or log.Fatal

[Jan Mercl]

What library call would then a programmer have to use when the logic of his/her program (or an OS signal, ...) requires an unconditional, NQA exit? In other words, it seems to me like a questionable idea to, silently if not studying the docs enough, change the semantics of os.Exit just by importing some library.

[Russ Cox]

On Mon, Nov 7, 2011 at 04:43, Archos <raul...@sent.com> wrote:
> Is there any way to intercept calls to os.Exit ?

No, there isn't. There have been long discussions
about this. Searching the archives for 'atexit' should
turn them up.

Russ

[Archos]

This could be avoided if Go has a supervision system that allows kill
goroutines. At least in my case, I could substitute defers by it.

On Nov 7, 10:55 pm, Russ Cox <r...@golang.org> wrote:

[Archos]

Anyway, it would be solve the problem of the exit with an exit code
using os.Exit when there are defers in your program. But no to
intercept os.Exit

[Miki Tebeka]

One simple solution is not to use os.Exit but your own Exit which first calls "atexit" handlers and then calls os.Exit.
See (and maybe use) https://bitbucket.org/tebeka/atexit.

[chris dollin]

That doesn't work if you're using a library that calls os.Exit
(unless you're willing to take on the load of fetching it's
source and running edits over it each time it changes).

Chris

--
Chris "allusive" Dollin

[Kyle Lemons]

Or submitting a patch/pull request to the author to not use os.Exit or log.Fatal.  It's not particularly nice to do these things in a library that others might use anyway.

~K 

[John Asmuth]

On Wednesday, November 9, 2011 1:02:46 PM UTC-5, ehedgehog wrote:

That doesn't work if you're using a library that calls os.Exit

I think the solution there is to find another library!

I was once working on a server that was crashing for no apparent reason, with no error messages or any kind of indication of what was going wrong. I tracked it down to a call to system.exit() in an error condition in one of the imported modules. Fun way to waste a day!

[chris dollin]

Yeah, that too. But it depends on the other party /doing/ something,
which is not guaranteed.

[Miki Tebeka]

>> See (and maybe use) https://bitbucket.org/tebeka/atexit.

>That doesn't work if you're using a library that calls os.Exit

Libraries who call os.Exit should be avoided at all cost. ;)

[Archos]

A solution would be that Go would have a tool for looking for os.Exit
and log.Fatal in Go source files. This would avoid a lot of headaches

On Nov 10, 2:19 am, Miki Tebeka <miki.teb...@gmail.com> wrote:
> >> See (and maybe use)https://bitbucket.org/tebeka/atexit.

[David Symonds]

On Thu, Nov 10, 2011 at 7:00 PM, Archos <raul...@sent.com> wrote:

> A solution would be that Go would have a tool for looking for os.Exit
> and log.Fatal in Go source files. This would avoid a lot of headaches

It's called grep.

[Archos]

You give by fact 2 things:

* every developer know grep (and know to use it), included Windows
develpers
* they know that a possible error could be caused by the use of
os.Exit

One tool, included in Go toolchain, would be very useful to looking
for possible warning in source files.

On Nov 10, 8:09 am, David Symonds <dsymo...@golang.org> wrote:

[Archos]

Or simply, that at compiling a package, were shown a warning when it's
used os.Exit and log.Fatal

[Jan Mercl]

On Thursday, November 10, 2011 11:21:03 AM UTC+1, Archos wrote:

You give by fact 2 things:

* every developer know grep (and know to use it), included Windows
develpers

Grep has a 38 year old history. Nothing to do with being a Windows developer (aka it's not an excuse for anything).

 

* they know that a possible error could be caused by the use of
os.Exit

No such assertion was presented.

 

One tool, included in Go toolchain, would be very useful to looking
for possible warning in source files.

Anyone can just write and publish it. Though I doubt it would have any value - as a one special case tool instead of the general ones like grep (and friends).

[Jan Mercl]

On Thursday, November 10, 2011 11:27:50 AM UTC+1, Archos wrote:

Or simply, that at compiling a package, were shown a warning when it's
used os.Exit and log.Fatal

1) [568]g compiler produces no warning by design.

2) Compiler giving a warning on a library call, which is not part of the language, so the compiler has no understanding of what that library call does - that's not a good idea.

[Archos]

On Nov 10, 11:09 am, Jan Mercl <jan.me...@nic.cz> wrote:
> On Thursday, November 10, 2011 11:21:03 AM UTC+1, Archos wrote:
>
> > * every developer know grep (and know to use it), included Windows
> > develpers
>
> Grep has a 38 year old history. Nothing to do with being a Windows
> developer (aka it's not an excuse for anything).

The history has not something to see with the fact of that Windows
comes without grep (by default).

> > * they know that a possible error could be caused by the use of
> > os.Exit
>
> No such assertion was presented.

Then, for that case, like a developer doesn't know if there is an
error due to os.Exit, the best would be a tool that looks for those
warnings.

> > One tool, included in Go toolchain, would be very useful to looking
> > for possible warning in source files.
>
> Anyone can just write and publish it. Though I doubt it would have any
> value - as a one special case tool instead of the general ones like grep
> (and friends).

Yes, of course, But it would be very helpful if were included in the
Go toolchain to detect those possible errors.

[Jan Mercl]

On Thursday, November 10, 2011 12:20:27 PM UTC+1, Archos wrote:

> Grep has a 38 year old history. Nothing to do with being a Windows 
> developer (aka it's not an excuse for anything). 
The history has not something to see with the fact of that Windows 
comes without grep (by default). 

So? Should then also the Go language project developed for Unix/POSIX like operating systems became rid of all Unix/POSIX tools only because Google is so nice and continuously supports the Windows port, where some of those tools are not available by default (but available for free in a matter of minutes)? What about say yacc involved in building the compiler? And there are other Unix originated tools used.

I don't care about anyone's preferred OS of choice. But it would sound to me like arrogance to complain about problems caused by my very own choice - when the authors of some project have chosen something else and I only don't know/have/understand that OS or it's standard/notoriously used tools.

 

> > * they know that a possible error could be caused by the use of 
> > os.Exit 
> 
> No such assertion was presented. 
Then, for that case, like a developer doesn't know if there is an 
error due to os.Exit,

Correct use of os.Exit is not an error at all.

 

the best would be a tool that looks for those 
warnings. 

I respect that opinion. My opposite opinion was stated already.

 

> > One tool, included in Go toolchain, would be very useful to looking 
> > for possible warning in source files. 
> 
> Anyone can just write and publish it. Though I doubt it would have any 
> value - as a one special case tool instead of the general ones like grep 
> (and friends). 
Yes, of course, But it would be very helpful if were included in the 
Go toolchain to detect those possible errors. 

Someone may see it helpful. I see it useless or at least not worth the effort to write it.

[Steve McCoy]

FYI, Windows doesn't have grep, but it does come with findstr, which has a pretty good overlap with the useful features of grep: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/findstr.mspx

[Archos]

On Nov 10, 12:02 pm, Jan Mercl <jan.me...@nic.cz> wrote:
> On Thursday, November 10, 2011 12:20:27 PM UTC+1, Archos wrote:
>
> > > Grep has a 38 year old history. Nothing to do with being a Windows
> > > developer (aka it's not an excuse for anything).
> > The history has not something to see with the fact of that Windows
> > comes without grep (by default).
>

> I don't care about anyone's preferred OS of choice. But it would sound to
> me like arrogance to complain about problems caused by my very own choice -
> when the authors of some project have chosen something else and I only
> don't know/have/understand that OS or it's standard/notoriously used tools.

It is all about to facilitate the debugging with such tool to
developers independently ot its operating system. In change,
arrogance, maybe, is want everybody know grep, have installed it, and
know which strings have to looking for a possible warning for those
strings... Instead of to have a tool that does all magic.

[Paul Borman]

As pointed out, Windows' version of grep is called findstr.  Grep is just the canonical name for a program that search the contents of files looking for a string (or pattern).  It just happens that many systems have a command also called grep.  It just means global/regular expression/print, or g/re/p, which worked in the editor ed.  It is a pretty simple and straightforward concept.

I think the point is not about grep but that most programmers already have tools to find string patterns in files.  Why right a special case one?

What about libraries that print to os.Stdout, or to os.Stderr?  There are countless things like this.  The important thing is for the libraries to document what they do and for library designers think about the consequences of their choices.  For example, myy log package has a log.Fatal that calls log.Exit.  Initially log.Exit is pointed at os.Exit but the program can repoint it if needed (in particular, my main work cannot afford to have someone call os.Exit)

[DisposaBoy]

Perhaps it may be to your benefit if you were to define what this *tool* does. From reading the messages here all I can see is that you want a tool that checks for the use of os.Exit etc. which doesn't make any sense because if their use (in general) was bad then they wouldn't exist in the first place.

[Archos]

On Nov 10, 4:49 pm, Paul Borman <bor...@google.com> wrote:
> As pointed out, Windows' version of grep is called findstr.  Grep is just
> the canonical name for a program that search the contents of files looking
> for a string (or pattern).  It just happens that many systems have a
> command also called grep.  It just means global/regular expression/print,
> or g/re/p, which worked in the editor ed.  It is a pretty simple and
> straightforward concept.

Thanks for the explanation about grep. I didn't know that it were in
the toolchain of systems based in Unix neither how it works. It has
been very did

> I think the point is not about grep but that most programmers already have
> tools to find string patterns in files.  Why right a special case one?

Of course that the point is not about grep. It's about a tool to
looking for possible warnings in the code since the compilers produces
no warning by design.

Of the same way that gofix has been added to the Go's toolchain. You
know, there is a stream editor in systems based in Unix (and ported to
Windows), called sed, which allows apply transformations to text. And
it has a 37 year old history so there is not excuse for developers
don't know about how to use it; in this case it was only necessary to
add the substitutions into a sed script.

> What about libraries that print to os.Stdout, or to os.Stderr?  There are
> countless things like this.

Those libraries that print there doesn't interrumpt a program like it
is done by os.Exit.

[Paul Borman]

On Thu, Nov 10, 2011 at 2:09 PM, Archos <raul...@sent.com> wrote:

> What about libraries that print to os.Stdout, or to os.Stderr?  There are
> countless things like this.

Those libraries that print there doesn't interrumpt a program like it
is done by os.Exit.

This is my point, each program has its own sensitivity.  A program that is expecting to use standard input and output (for example, any program started by inetd) will be messed up by some part of the library writing to either standard out or error.  It is just a different sort of failure.

You have identified one such issue.

The earlier statement that library packages in general should not call os.Exit is the best answer to this, I think.

    -Paul

[Ugorji Nwoke]

There's a tool: govet.

It's job is to do simple checking of go source code for some possible programmer issues. It currently does a few:

- check printf style statements to warn about wrong use

- check correct implementation signatures for common std library interfaces (e.g. GobDecode, WriteTo, etc)

This is the tool that can do warnings. But the warnings are for things that can trip up go programmers e.g.

- I thought I was implementing io.ByteReader, but I forgot to ensure signature returns an error

- ...

Having said that, this case of "find me the calls to os.Exit and log.Fatal" can easily be done with grep (or any other basic text file search tool), and should not be included in any go tools. Go tools have intelligence and should offer clear benefits. This is not such a case.