手机网站 html,太原免费自助建站模板,英雄联盟怎么做直播网站,做网站编码sap打勾选项记录Java开发人员可以做很多事情来使自己的生活以及维护该代码的其他人的生活更加轻松。 在本文中#xff0c;我将探讨开发人员可以采用的一种非常简单的方法#xff0c;以使每个人都更轻松。 对于每个阅读这篇文章的人来说#xff0c;这篇文章的要点似乎都很明显… sap打勾选项记录 Java开发人员可以做很多事情来使自己的生活以及维护该代码的其他人的生活更加轻松。 在本文中我将探讨开发人员可以采用的一种非常简单的方法以使每个人都更轻松。 对于每个阅读这篇文章的人来说这篇文章的要点似乎都很明显但是我发现这样做的频率比我预期的要少得多。 总之开发人员通常应记录它们的值开关 当该值不被任何明确的表示对-ing case是内声明switch 。 在进行具体说明之前我将添加一些警告。 有时记录switch到的值与case没有明确匹配可能没有意义。 其中一些列在这里。 所打开的值是敏感的出于安全原因不应记录。 在许多情况下打开该值都不会导致匹配因此开发人员不希望不必要地登录。 可以提供一个default值该default值对于没有匹配case块的任何值都将始终有效这似乎很少。 在我所见的情况下这是导致其成为我主要宠物怒气的原因之一上述警告均未适用。 实际上在大多数情况下开发人员已在default块中提供了一条记录的消息警告该值是意外的但同一开发人员未能提供不匹配的候选值。 下一个代码清单显示了一个人为的示例。 枚举default 不带switch候选值登录 /*** Provides the Roman numeral equivalent of the* provided integer.* * param integer Integer for which Roman numeral* equivalent is desired.* return Roman numeral equivalent of the provided* integer or empty string () if Im not aware of* the Roman numeral equivalent.*/
public String getRomanNumeralEquivalent(final int integer)
{String romanNumeral;switch (integer){case 0:romanNumeral nulla;break;case 1:romanNumeral I;break;case 2:romanNumeral II;break;case 3:romanNumeral III;break;case 4:romanNumeral IV;break;case 5:romanNumeral V;break;case 6:romanNumeral VI;break;case 7:romanNumeral VII;break;case 8:romanNumeral VIII;break;case 9:romanNumeral IX;break;case 10:romanNumeral X;break;default:out.println(Unexpected integer was provided.);romanNumeral ;break;}return romanNumeral;
} 此处的问题实际上是开发人员应避免的更普遍问题的特定示例没有足够上下文的日志。 在某些情况下提供使日志消息更有用的上下文类型可能很困难或计算量很大。 但是在switch语句中通常不是这种情况我们可以在其中轻松记录尝试switch的值。 在上面的代码清单中将仅告诉开发人员在部署中支持运行时问题的开发人员“提供了意外的整数”。 没有任何上下文很难知道提供的整数是什么并且如果不知道候选整数就很难跟踪发生了什么甚至无法重现它。 只需很少的精力就可以使此default日志记录语句有用这将在下一个代码清单中显示。 构造更好的default日志语句 default:out.println(Unexpected integer ( integer ) was provided, so empty String being returned for Roman Numeral.);romanNumeral ; “增强的”日志消息指示正在打开哪个整数并添加了由于该整数不是期望的整数而返回的内容。 第二部分对于开发人员而言不是必需的因为静态代码将向开发人员显示在这种“默认”情况下返回的内容。 但是正在打开的整数的日志记录非常有价值因为以后没有很好的方法来访问此信息除非其他地方的其他日志消息清楚地表明正在打开的内容。 我无数次成为开发人员未提供此简单上下文的受害者。 这使原本很容易诊断的事情变得更加困难。 在极端情况下我必须将此上下文添加到日志消息中并等待再次遇到它。 如果开发人员在编写代码时添加了简单的上下文信息则可以更轻松地解决此问题。 在编写自己的switch语句时我希望将这一概念更进一步。 即使我的switch明确涵盖了所有可能的当前 case我也通常添加一个default块。 在编写本文时此default块是不必要的并且“永远不会被调用”但是我将其添加到了面向将来的switch语句中可以使用单元测试来实现类似的保护。 我添加了提供给switch语句的意外候选值的日志记录以便在代码“上游”添加另一种情况时我的switch会在遇到意外值时Swift告诉我并告诉我该意外值是什么。 通常会发现在不匹配case的情况下为switch语句提供候选值是一种特殊情况。 在这种情况下抛出异常比仅记录异常情况更合适。 一个标准的异常例如IllegalArgumentException可以很好地解决此问题从某种意义上说它是switch语句的非法参数但是我偶尔也编写了一个自定义的异常来帮助解决这个问题。 当我决定实现并使用此自定义异常时做出该决定的部分原因是抛出该异常会鼓励开发人员提供被打开的对象作为异常构造函数的一部分。 接下来显示此类自定义异常的典型示例。 SwitchOptionNotExpectedException.java package dustin.examples.switchdemo;/*** Exception used to communicate a candidate value for* a {code switch} statement not being matched by any* of the explicitly provided {code case} blocks.*/
public class SwitchOptionNotExpectedException extends RuntimeException
{/*** Object being switched on for which no matching* {code case} clause existed.*/private final Object switchedObject;/*** Constructor accepting exception message and the instance* upon which the {code switch} was being attempted when no* matching {code case} was found.** param newMessage Exception summary message.* param newSwitchedObject Object being switched on for* which there was no explicitly specifed {code case}.*/public SwitchOptionNotExpectedException(final String newMessage, final Object newSwitchedObject){super(newMessage (unable to switch on String.valueOf(newSwitchedObject) ));switchedObject newSwitchedObject;}/*** Constructor accepting the instance upon which the {code switch}* was being attempted when no matching {code case} was found.** param newSwitchedObject Object being switched on for* which there was no explicitly specified {code case}.*/public SwitchOptionNotExpectedException(final Object newSwitchedObject){super(Switch statement did not expect String.valueOf(newSwitchedObject) .);switchedObject newSwitchedObject;}/*** Provides String representation of the object being* switched upon.** return String representation of the object being* switched upon.*/public String getSwitchedObjectString(){return String.valueOf(switchedObject);}/*** Provides type of object being switched upon.** return Type of the object being switched upon or* {code null} if that switched upon object is null.*/public Class getSwitchedObjectType(){return switchedObject ! null ? switchedObject.getClass() : null;}
} 开发人员是否只是简单地记录未找到切换候选者或引发异常是对此的响应通常应记录或将打开的值记录在异常中或包括在异常中以使诊断问题变得更加容易。 上面的自定义异常将自动提供该消息而与使用的构造函数无关只要开发人员提供打开的对象即可。 在这种情况下开发人员必须竭尽全力不提供该对象而不仅仅是忽略或忘记包含它。 在排除了不适合登录或写出不匹配值的情况之后开发人员最有可能无法表明该值的根本原因就是根本没有考虑它。 在编写代码时对开发人员“显而易见”的是任何意外情况“都不会发生”或者如果确实发生了那么价值是显而易见的。 在这些类型的消息或与此有关的任何日志消息中不包括上下文的另一个可能原因是匆忙或懒惰。 开发人员可能知道最好提供这些详细信息但不想花时间去做。 这是后一个原因有时会鼓励我编写一个自定义异常如上所示。 对开发人员来说调试和维护生产软件是宝贵的经验因为它可以帮助开发人员更好地了解他们的行为或缺乏行为如何使将来的工作更加困难。 通常有责任心的开发人员可以通过在记录的消息中提供上下文信息来帮助其他人可能还有他或她自己特别是对于警告错误和异常情况。 特别是增加什么价值的背景下正在switch时没有找到匹配的-ed是很容易做到可能相当多的时间保存自己其他开发人员和客户的未来。 翻译自: https://www.javacodegeeks.com/2017/11/log-unexpected-switch-options.htmlsap打勾选项记录
