sap打勾选项记录_记录意外的开关选项

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 I'm 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.html

sap打勾选项记录