# Common Apex Usage Patters

## Basic Apex Logging

Now that you're familiar with the [basic philosophy of Pharos Triton](/pharos-triton/apex-logging-basics.md), let's take a look at an example of apex logging. There are a number of ways to do logging ranging, from straightforward to very complex. We'll start with the basics and gradually move on to more advanced patterns and use cases. 

In this scenario we'll take a look at a simple code snippet that performs a DML statement. The DML statement is wrapped into a try/catch block, where any potential exceptions can be handled. This scenario can take place anywhere: triggers, LWC Apex controllers, or even custom rest methods.  

{% code lineNumbers="true" fullWidth="false" %}

```apex
public void basicApexLogging() {
        Triton.instance.startTransaction();
	Triton.instance.debug(TritonTypes.Type.Backend,//type
			TritonTypes.Area.Accounts,//functional area
			'Apex logging example Pre-dml',//summary
			'Pre dml update. Processing account records'); //details 
	try {
		List<Account> accounts = [SELECT Id, Name FROM Account LIMIT 1];
		if (!accounts.isEmpty()) {
			Triton.instance.debug(TritonTypes.Type.Backend, 
					TritonTypes.Area.Accounts,   
					'Account records found!',
					'Pre dml update. Processing account records');		
			accounts[0].Name = 'Logging rules!';
			update accounts;
		}
	} catch (Exception e) {
		//uh-oh... we have an Exception on our hands. Let's log that!
		Triton.instance.error(TritonTypes.Area.Accounts, e);
	} finally {
		Triton.instance.stopTransaction();
	}
}

```

{% endcode %}

Let's take a closer look at this snippet. There are a few take aways in the code above:

* The use of *start/stopTransaction().* This initiates a new transaction context within Pharos and ensures that all subsequent logs are grouped under a single umbrella—more specifically, under the first log generated in the sequence.  See the log structure [detailed below](#parent-and-child-logs).

{% hint style="info" %}
If you have more logging to perform that you wish to group under the same umbrella, you can pass around the transaction Id (obtained from the *Triton.instance.TRANSACTION\_ID* property). This would allow you to span across Salesforce transactions to trace a complex process.
{% endhint %}

* Note the use of Type and Area values. You can check out the [general guidelines here](/pharos-triton/apex-logging-basics.md#enums).
* The use of *debug()* and *error()* methods. These simply provide a shorthand for creating log records with different categories, and different log levels. Note that different parameters are provided to *debug()* and *error()* methods.&#x20;
* The use of a *finally{}* construct. This ensures that *stopTransaction()* is the last method that executes in any event.&#x20;

{% hint style="info" %}
If you exceed a **governor limit** somewhere in your transaction, there's no guarantee that the finally{} block will execute, and with it the *stopTransaction().*

If *stopTransaction()* is not called, Pharos Triton simply stops logging under the parent log. In the example above, that poses no problem as there is no further logging after the *flush()*.&#x20;
{% endhint %}

### Parent and Child Logs

Let's now assume that there is an exception raised during the DML operation. This will result in the following log records created:

* **A parent debug log generated on line (3)**
  1. A child debug log generated on line (10)
  2. A child Apex error log generated on line (19)
     * **An issue record** will also automatically get created for this log. Issues, by default, are only created for error logs. Debug and other log categories such as Event or Warning do not generate issues by default. This behavior is customizable in the [logging methods detailed here.](/pharos-triton/methods-reference/apex-methods-reference.md)

{% hint style="info" %}
If no *startTransaction()* call is made Pharos Triton will simply create the logs without associating them together under a common parent. This would result in the log structure below.

* A parent debug log generated on line (3)
* A parent debug log generated on line (10)
* A parent Apex error log generated on line (19)
  * An issue record will also automatically get created for this log. Similar to the example above. Issue creation behavior is not impacted by transactional logging.
    {% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://triton.pharos.ai/pharos-triton/common-apex-usage-patters.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.