.net core docker容器在生产中由于Null Exception而以错误代码139退出。

Question

我有一个docker容器，上面有.net core web app.docker已经退出，错误代码139.Docker inspect没有om指示当我看日志时，我看到这个，没有更多的提示。

Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.
   at Services.Web.Services.ProductClient.RunCient.<>c__DisplayClass5_0.<<ScrapeProfileInfo>b__0>d.MoveNext() in /src/Services.Web/Services/Clients/ProductClient.cs:line 30
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__139_1(Object state)
   at System.Threading.QueueUserWorkItemCallback.<>c.<.cctor>b__6_0(QueueUserWorkItemCallback quwi)
   at System.Threading.ExecutionContext.RunForThreadPoolUnsafe[TState](ExecutionContext executionContext, Action`1 callback, TState& state)
   at System.Threading.QueueUserWorkItemCallback.Execute()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

在... ProductClient.cs: line 30 没有潜在风险的null异常...。if (txt == string.Empty) return;

1. 是什么原因导致了这个异常，这一行完全没有风险？
2. Docker不应该仅仅因为一个异常而存在，它是否暗示了可能发生的事情？

我是在Google云平台上托管的，docker在ubuntu服务器上，在compute engine下... (docker-compose)

更新 该构建是一个docker构建 RUN dotnet build "EyezServices.Web.csproj" -c Release -o /app/build 没有使用c# nullable功能

谢谢你

Answer 1

我觉得问题不在docker，更有可能是在c#中。

你可以尝试的事情。

1. 把构建模式改为调试 -c Debug. 在优化过程中，C#编译器可以内联一些函数，NPE可能来自不同的行，而不是异常状态(参见 https:/developer.azurewebsites.net201511net-c-build-release-model with-full-stack-trace-and-line-numbers。)
2. 使用nullables。它对跟踪潜在的NPE问题有很大的帮助。
3. 试着在之前检查null，添加一个测试子句 if (txt is null) 看看你是否确定那里的txt不是空的。