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打勾選項記錄

總結

以上是生活随笔為你收集整理的sap打勾选项记录_记录意外的开关选项的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。