从模板执行中滤除损坏的管道错误 [英] Filter out broken pipe errors from template execution

问题描述

这与滤除破管错误类似，但有复杂性 - 当用户在模板执行时按下浏览器上的停止按钮（html / template.Execute或text / template.Execute），会发生管道故障错误。

但是，我相信由text / template包返回的错误仅仅是* errors.errorString类型，因为损坏的管道消息似乎被包装在其他一些信息文本中，因此没有可以对net.OpErr进行类型断言比较的目的。

例如，一个典型的破管错误字符串看起来像

write tcp 127.0.0.1:60739：broken pipe

执行模板返回的管道错误字符串如下所示：

$ b $

template：header.html：1：0：在< div id =header ...>执行header.html：write tcp 127.0 .0.1：60739：broken p Ipe

我有一个用Go编写的生产Web应用程序，并且在我的错误日志的其余部分中，现在我不知道如何过滤掉破坏的管道，而不是使用类似strings.Contains这样脏的东西。

解决方案

这是一个记录问题。我宁愿在我的日志中有更多的信息，也不得不过滤它，而不是在这个错误信息是问题的唯一痕迹时尝试追踪一个错误。

正如你所提到的，错误是通过 errors.New 创建的。你所拥有的只是一个字符串，所以从执行模板过滤这个错误的唯一方法是检查所述字符串，可能使用 strings.Contains 。

处理这个问题的另一种方法是将 io.Writer 包装成破碎的管道，然后悄悄丢弃任何后续的写入。

This is similar to Filter out broken pipe errors , but with complications - when a user presses the "stop" button on their browser while a template is executing (html/template.Execute or text/template.Execute), a broken pipe error occurs.

However, I believe that the error returned by the text/template package is simply of type *errors.errorString as the broken pipe message appears to be wrapped in some other informational text and so no type assertion can be made to net.OpErr for comparison purposes.

For example, a typical broken pipe error string would look like

write tcp 127.0.0.1:60739: broken pipe

A broken pipe error string returned by an executing template looks like:

template: header.html:1:0: executing "header.html" at <div id="header...>: write tcp 127.0.0.1:60739: broken pipe

I have a production web application written in Go and am sick of visually filtering out broken pipe errors in the rest of my error logs but right now I have no clue how to filter out broken pipe other than using something dirty like strings.Contains.

解决方案

This is a logging issue. I'd rather have more information in my logs and have to filter it, than try and track down a bug when this error message is the only trace of the problem.

As you mentioned, the error is created via errors.New. All you have is a string, so the only way to filter this error from executing the template is going to be by inspecting said string, probably with strings.Contains.

Another way to handle this would be to wrap your io.Writer to catch the broken pipe, then silently throw away any subsequent writes.

这篇关于从模板执行中滤除损坏的管道错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！