我是否应该测试 Main 的 args 数组中值的无效性
Should I test for nullity of values in the args array of Main
根据这个 post :
is this overkill for assessing Main(string[] args)
中的 args 似乎永远不能为 null
static void Main(string[] args)
好的,但是,假设 args.Length == 1 是真的,是否可以使用 args[0] == null ?
第一个观察:字符串数组可以有空元素
第二个观察:如果 main 是用命令行调用的,我不知道如何传递 null,我认为这是不可能的,
第三个观察:另一方面(这有点牵强)有可能某些代码调用
Program.Main(new string[]{null})
因此,有可能产生在 args 数组中获得空值的情况。
所以问题是:
在 main 的参数中测试无效性是矫枉过正还是好的做法? (特别是考虑到 main 在第三次观察中被调用 like 是一种不太可能的情况)
例如:以下是正确的吗?
static void Main(string[] args)
{
if(args.Length == 1)
{
var v = args[0].Replace("Foo", "Bar");//hope args[0] is not null
或者我应该这样做
static void Main(string[] args)
{
if(args.Length == 1 && args[0] != null)
{
//...
注意:我将其标记为 C#,但我想这也适用于其他语言
正如您在问题中所写,static void Main()
是 private
(因为如果缺少 private
则隐含)。调用它的人必须使用反射,并且必须知道他正行走在小冰上。他具有传递正确参数的 duty/obligation(其中 "correct" 在这种情况下是 "no null
values" 任何地方)。如果他不这样做,他得到一个NullReferenceException
,错就在他。所以答案是"you have no duty to check for null
values"(我不会这样做。这太过分了)
如您所写(以及在参考答案中所写),您无法从命令行传递 null
,因此这消除了另一种可能性。
it is possible that some code calls
Program.Main(new string[]{null})
程序确实可以调用 Program.Main(null)
,所以 args
确实可以为 null。
问题是,你为什么要这么做?为什么要 Main(null)
或 Main(new string[]{null})
?
确实,您为什么要显式调用 Main
?
要么你在你的代码中做了一些愚蠢的事情,在这种情况下出现问题然后意识到你做了一些愚蠢的事情是一件好事,或者有人在他们的代码中做了一些愚蠢的事情使用反射来访问你的代码,在这种情况下,最好让事情抛出异常并中断并希望说服然后不要那样做!*。
(在某些特殊情况下,可以通过反射为 Main()
的经过深思熟虑的调用提出论据,但随后传入空参数并没有经过深思熟虑并且如此专业我会说来电者有责任考虑这种可能性)。
如果这种愚蠢行为很可能发生,那么人们可以为测试做一个理由,然后尽早抛出异常,但我不太可能倾向于让事情随心所欲地破坏。
*“医生!医生!我做的时候好痛!” “那就不要那样做!”
操作系统永远不会传递 args 数组中的空元素。如果您正在编写旨在从命令行执行的应用程序,那么您有权依赖操作系统来履行此合同。
如果有人(或您)编写调用者来调用您的代码,那么调用者有责任履行合同或捕获并处理可能因违反合同而导致的任何异常。
根据这个 post :
is this overkill for assessing Main(string[] args)
中的 args 似乎永远不能为 nullstatic void Main(string[] args)
好的,但是,假设 args.Length == 1 是真的,是否可以使用 args[0] == null ? 第一个观察:字符串数组可以有空元素
第二个观察:如果 main 是用命令行调用的,我不知道如何传递 null,我认为这是不可能的,
第三个观察:另一方面(这有点牵强)有可能某些代码调用
Program.Main(new string[]{null})
因此,有可能产生在 args 数组中获得空值的情况。
所以问题是:
在 main 的参数中测试无效性是矫枉过正还是好的做法? (特别是考虑到 main 在第三次观察中被调用 like 是一种不太可能的情况)
例如:以下是正确的吗?
static void Main(string[] args)
{
if(args.Length == 1)
{
var v = args[0].Replace("Foo", "Bar");//hope args[0] is not null
或者我应该这样做
static void Main(string[] args)
{
if(args.Length == 1 && args[0] != null)
{
//...
注意:我将其标记为 C#,但我想这也适用于其他语言
正如您在问题中所写,static void Main()
是 private
(因为如果缺少 private
则隐含)。调用它的人必须使用反射,并且必须知道他正行走在小冰上。他具有传递正确参数的 duty/obligation(其中 "correct" 在这种情况下是 "no null
values" 任何地方)。如果他不这样做,他得到一个NullReferenceException
,错就在他。所以答案是"you have no duty to check for null
values"(我不会这样做。这太过分了)
如您所写(以及在参考答案中所写),您无法从命令行传递 null
,因此这消除了另一种可能性。
it is possible that some code calls
Program.Main(new string[]{null})
程序确实可以调用 Program.Main(null)
,所以 args
确实可以为 null。
问题是,你为什么要这么做?为什么要 Main(null)
或 Main(new string[]{null})
?
确实,您为什么要显式调用 Main
?
要么你在你的代码中做了一些愚蠢的事情,在这种情况下出现问题然后意识到你做了一些愚蠢的事情是一件好事,或者有人在他们的代码中做了一些愚蠢的事情使用反射来访问你的代码,在这种情况下,最好让事情抛出异常并中断并希望说服然后不要那样做!*。
(在某些特殊情况下,可以通过反射为 Main()
的经过深思熟虑的调用提出论据,但随后传入空参数并没有经过深思熟虑并且如此专业我会说来电者有责任考虑这种可能性)。
如果这种愚蠢行为很可能发生,那么人们可以为测试做一个理由,然后尽早抛出异常,但我不太可能倾向于让事情随心所欲地破坏。
*“医生!医生!我做的时候好痛!” “那就不要那样做!”
操作系统永远不会传递 args 数组中的空元素。如果您正在编写旨在从命令行执行的应用程序,那么您有权依赖操作系统来履行此合同。
如果有人(或您)编写调用者来调用您的代码,那么调用者有责任履行合同或捕获并处理可能因违反合同而导致的任何异常。