Summary

1. Debug Module
2. Singleton Pattern
   1. Private constructor
3. Debug module composition
4. Methods
   1. What happen as result
   2. Main methods
      1. log()
      2. log(Object key, Object value)
      3. log(Exception e)
      4. log(Map<Object, Object> debugMap)
      5. log(Map<Object, Object> debugMap, Exception e)
   3. Important details
      1. You can use set methods to change custom settings:
         1. Customize settings
         2. Serialize values
         3. Flow settings
   4. Other methods
      1. start()
      2. end()
      3. setStart()
      4. setEnd()

1. [Salesforce] Debug Module

Debug class to support a better understand of what is going on during processing of development, or about errors and exceptions.

2. [Pattern] Singleton

• This class use the sigleton pattern, where only one instance of this class is used since the start of the context (processment) until de end of the context.
• I am trying to use single responsabilities to, try to creating little methods to maintain code reusability, and simplify development of test class and methods.

I. So the constructor is private

The class has only one Debug type variable 'INSTANCE':

That will be used for call the methods with the follow 'getInstance' method:

3. Debug module composition

• This project contains only two classes.

→ Debug.cls
→ DebugTest.cls

• The main class is Debug, wich have some util methods to help developer debug and understand what is going on.
• In the next content, i will show you how to use this util methods with some prints of samples.
• In the end, i will talk a little about customize the logic of this methods, but it probably will be very rare to use.

4. Methods

• The main proposite of this class is to log some key points to understand the code, as what 'class', 'method', what line the debug log method was called, and key and values for the dev understand what is happening in the logic of the class, and where it is.

I. What happened?

1. Class name: As the method was called from executed anonymous block (developer console), its name appeared in the log message.
2. Method name: As the method was called out of a method, nothing appeared in the method name.
3. Line number: As the method was called from the first line, the first line was showed in the log message.

II. Main methods

a. log()

→ Obs: This method call a debug log message with basic information as showed above but, we will present it called from a simple class here.

 [Screen shoots]
     

→ Explanation: In the screen shoots above we can see the key points easily, as 'class name', 'method name', and 'line number', but it is the most simple sample here.

---

b. log(Object key, Object value)

→ Obs: Here, we start to add some complexity to the debug logs. We can add lines, and this lines ('key → values') to see the result of some proccessment, or see what is happening insed the code.
→ Obs²: As the parameters are of type Object, it can accept any type of values, as SObject, maps, lists, and any other primitive or complex types.

 [Screen shoots]
   

→ Explanation:
1. The 'key' value is presented as an key in the message to identify the value you want to see.
2. The 'value' is presented to visualize what is saved inside the variable.

---

c. log(Exception e)

→ Obs: This is my favorite one. Every dev format a exception message with his own pattern, what make the code different, and can add alot of lines to the project, but this method format the message with a single and easy pattern that help to undertand the key points.

 [Screen shoots]
   

→ Explanation:
1. In the message, a new section called 'Exception Data' is created, displaying what is important.
2. With this, we can implement exception log as simple, clear and fast as possible.

---

d. log(Map<Object, Object> debugMap)

→ Obs: Passing a Map<Object, Object> , where the key map is the 'key' in the message, and the value map, is the 'value' in the message, we can log alot of values to see all we want easly.

 [Screen shoots]
   

→ Explanation: Every '• key → value' use a different line to be displayed.

---

e. log(Map<Object, Object> debugMap, Exception e)

→ Obs: And we can combine the useful with the pleasant to present both the data that were used and the data of the exception generated to understand what happened.

 [Screen shoots]
   

→ Explanation: We can send at same time a key value map, with the exception threw to see everything easly.

---

III. Important details

• Some times, we try to log long messages, that some times can be hidden by developer log, or the log itself when opened in a IDE or text editor, but with this class, i prepared a break line function to break long values message, using a Regex expression, based in line size, and that use a default Break simbol, that can be customized using a set method. By default:

→ The split character simbol: A comma (,)
→ The minimum and max size to break a line (a space to try to find a split character): Min: 340 | Max: 400
→ Default regex expression: (?<=\\G.{340,400}),

a. You can use set methods to change custom settings:

Warning:

-Be carefull! Some complex, and long strings with a long split lenght (min → max) can generate a 'to complex regex' exception.

a. Customize settings

→ setMinSplitLenght
→ setMaxSplitLenght
→ setCharacterSplitSignal

b. Serialize values

• You can use a method to change the breakline to a serializiation, where the code stops to break line and convert the value to a JSON, where sometimes we can see all the line.

→ serializeLog

c. Flow settings

• Every customization is reseted after the end of the proccess to log the data by a method inside the proccess called 'cleanInstanceVariables'. So if you want to customize, you will need to change defaults again.

IV. Other methods

a. start()

→ Obs: This method is used in the place of 'log()' method without parameters. The difference between this two methos is only a aditional message showed indicating that the method you want to analize is 'starting...'.

 [Screen shoots]
   

→ Explanation: Add a aditional information saying the method analised is starting.

---

b. end()

→ Obs: Equals to the start, but is used to be placed in the end of the method.

 [Screen shoots]
   

→ Explanation: Add a aditional information saying the method analised is ending.

---

c. setStart()

→ Obs: You can use 'setStart()' method to add this additional message in a more complex log, to analyse for example parameters that the method received and its values when starting the method.

 [Screen shoots]
     

→ Explanation: Add a aditional information to a more complex log, saying the method analised is starting.

---

d. setEnd()

→ Obs: You can use 'setEnd()' method to add this additional message in a more complex log, to analyse for example parameters when the method is ending, and see what happened during proccessment.

 [Screen shoots]
     

→ Explanation: Add a aditional information to a more complex log, saying the method analised is ending.