# Run helmut4 client in debug mode

## Disclaimer

{% hint style="danger" %}
**Important**\
The *<mark style="background-color:red;">connection speed & response will be significant slower</mark>*, as everything will be logged
{% endhint %}

If you need to debug the local helmut4 client on windows or macintosh clients you can do this with the following commands.

*Please keep in mind that this should only be used for debugging purpose not for daily use!*

## Windows

Open a command prompt (***with admin privileges***) and execute this command:

```shell
"C:\Program Files\MoovIT GmbH\Helmut4\jre\bin\java.exe" -jar "C:\Program Files\MoovIT GmbH\Helmut4\HelmutClient.jar" --logging.level.org=DEBUG
```

## Macintosh

Open a terminal window and execute the following two commands (***with admin privileges***)

```bash
"/Applications/Helmut4.app/Contents/Resources/jre/bin/java" -jar "/Applications/Helmut4.app/Contents/Resources/HelmutClient.jar" --logging.level.org=DEBUG
```

## Debug Options

### How to Choose the Right Level:

* **TRACE**: Use for highly detailed debugging during development.
* **DEBUG**: Use for regular debugging when specific issues occur.
* **INFO**: Use for monitoring normal application operations in production.
* **WARN**: Use to track potential problems without flooding logs.
* **ERROR**: Use for critical issues requiring immediate attention.
* **FATAL**: Use to identify severe errors leading to system failure.
* **OFF**: Use to disable logging entirely.

### Debug level

Here’s a detailed explanation of the logging levels you can configure for your application:

#### **1. OFF**

* **Purpose**: Turns off logging entirely.
* **Use case**: When you want to disable all logging, typically in production for maximum performance.
* **Behavior**: No logs will be recorded or output, regardless of the severity.

#### 2. **FATAL**

* **Purpose**: Logs critical errors that cause the application to terminate unexpectedly.
* **Use case**: Detecting system crashes or unrecoverable states.
* **Behavior**: Only logs events of `FATAL` severity.
* **Example**: A missing critical resource or an exception causing immediate shutdown.

#### 3. **ERROR**

* **Purpose**: Logs errors that affect the normal operation but don’t cause the application to crash.
* **Use case**: Debugging runtime issues or failures in specific operations.
* **Behavior**: Logs `ERROR` and `FATAL` events.
* **Example**: A failed database connection or invalid user input causing a function to fail.

#### 4. **WARN**

* **Purpose**: Logs potentially harmful situations that could indicate a problem.
* **Use case**: Monitoring for conditions that don’t cause errors but may require attention.
* **Behavior**: Logs `WARN`, `ERROR`, and `FATAL` events.
* **Example**: Deprecated API usage or a configuration mismatch.

#### 5. **INFO**

* **Purpose**: Logs general information about the application’s progress or state.
* **Use case**: Standard logging for normal operations.
* **Behavior**: Logs `INFO`, `WARN`, `ERROR`, and `FATAL` events.
* **Example**: Application startup messages, configuration details, or status updates.

#### 6. **DEBUG**

* **Purpose**: Logs detailed information primarily useful for developers during debugging.
* **Use case**: Troubleshooting issues or understanding internal workflows.
* **Behavior**: Logs `DEBUG`, `INFO`, `WARN`, `ERROR`, and `FATAL` events.
* **Example**: Method entry and exit points, parameter values, or intermediate states.

#### 7. **TRACE**

* **Purpose**: Logs very detailed information, including fine-grained events within the application.
* **Use case**: Deep debugging to trace execution paths or diagnose complex issues.
* **Behavior**: Logs all events, including `TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR`, and `FATAL`.
* **Example**: Low-level details such as thread states, detailed computations, or internal operations.