How do we debug what went in wrong in the libraries that we use with "return error instead of throwing exception" model?

<p>I&#39;m faced with a little challenge today. I&#39;m using a library which ultimately uses sycalls to do the stuff. If a syscall fails, it returns with an error obtained from the syscall itself. As these errors come from the native apis (like winapi?), they are sometimes generic (like system cannot find path specified). If they are from go code/library code itself I can just do a find on the files of interest. But how can I know exactly which line returned in the call stack with that error without some kind of mechanism. runtime.Stack() is not an option since we are talking about the existing library code. Any ideas?</p> <hr/>**评论：**<br/><br/>epiris: <pre><p>In Windows errors always have a code that you can look up for the exact cause, so check the error value for a concrete type that contains the numeric code if it does&#39;t expose it in the string. Edit the library if it doesn&#39;t include this data and open a issue with them if possible.</p> <p>In general failures in Windows are almost always related to acls in one way or another, which usually propagate into the event viewer as well. Have it open at all times when writing software in that developer hostile environment.</p></pre>cilpam: <pre><p>thanks, this helps</p></pre>cilpam: <pre><p>Hey epiris, if you don&#39;t mind could you tell me if by ACLS you mean permissions? The issue I&#39;m facing only comes if I run via ssh terminal logged into remote Windows. Basically my program is trying to write to Windows credentials manager. (A specified login session doesn&#39;t exist. It may have been terminated) Underlying native API is CredWritew. I&#39;m using cygwin as ssh server. But thanks very much for event viewer tip.</p></pre>epiris: <pre><p>Yea, permissions. The fact it only happens during ssh is telling, Ssh server is probably running as network user, which you can think of like “nobody”. The path of least resistance is a windows service that runs under a service account with access to the api you want. Then write and deploy a small exe to manage it that you can use from ssh. The general problem your solving here is crossing user boundaries securely, so the same Unix solution space generally applies.</p> <p>More correct solution would probably be (windows service Local daemon) &lt;— (GRPC service listening remotely with client cert auth) | (grpc clients). When in windows world you need to be careful not to try to Unix your software into place, it’s a security nightmare as is so layering Cygwin on top of it is a bad idea. But if your risk / impact is low than it may be harmless. Good luck.</p></pre>cilpam: <pre><p>Actually, my problem is a little different. I&#39;m not actually writing anything that works in this kind of infrastructure. It&#39;s just enough for me to write a program which run in a box just fine. But when we want to execute that to try it out in a remote computer(for example, in a windows server), we are facing that issue. So, it seems like my problem is how to run a windows program in a remote windows with correctly with a right tool. May be I should use something other than Cygwin. But the program I&#39;m developing might be used by customers, and if they also use ssh to login to their windows, then they might also face the issue. Thank you</p></pre>zevdg: <pre><p>You could use <a href="https://github.com/derekparker/delve" rel="nofollow">delve</a>. Vscode integrates nicely with it as do a few other editors and IDEs.</p></pre>cilpam: <pre><p>thanks</p></pre>hipone: <pre><p>I&#39;d make a debug version of that external library and use it for debugging the problem. Log everything that is passed to this library on Go side, and do the same in the library - extend its source to log anything that comes back from WinAPI etc. Hopefully this would give you a hint what is going and where the bug may be.</p></pre>cilpam: <pre><p>Currently I&#39;m trying to single out the lines of code that potentially causing the issue and writing a small program of those lines to see if they are causing this issue. But it&#39;s very counter productive. Especially if we are coming from Java background..</p></pre>hipone: <pre><p>This boils down to the lack of GDB support for Go applications. There&#39;s nothing magical in Java / JNI.</p></pre>tv64738: <pre><p>Good libraries don&#39;t hide where the error originates from. For example, stdlib uses <a href="https://golang.org/pkg/os/#PathError" rel="nofollow">os.PathError</a>, <a href="https://golang.org/pkg/net/#OpError" rel="nofollow">net.OpError</a> and such to wrap the error in a way that tells you more than the underlying system error does.</p></pre>cilpam: <pre><p>In my case user.Current() from standard lib gives me an error. I will look if it gives more than that. If not I&#39;d standard libs themselves don&#39;t give debuggable errors, I&#39;m not so positive that third party libraries will give much more than that. It gets complicated with the fact that the errors I&#39;m facing are native API related.</p></pre>tv64738: <pre><p>It the stdlib error isn&#39;t &#34;debuggable&#34;, it&#39;s likely the operating system never gave Go anything useful either.</p></pre>