Transitions in UML state charts: better to use tri

In the design of UML state charts it appears that I can chose to use either triggers or guard logic to achieve transitions between states.

So which is better to use? Given the same logic for transition, does a trigger behave any differently than a guard? What are the benefits/drawbacks of one over the other?

Are there perhaps differences depending on the particular tool, or does the UML standard strictly define the behaviors of either method of transition?

I'm presently using Simulink Stateflow to design a state machine.

Those two are different concepts.

Trigger is an event occurrence which enables the transition, while guard is a condition that must be evaluated to true in order for the transition to proceed.

So you cannot use them interchangeably — they have different roles.

Also note that the default guard (if none is specified) is [true], so the trigger is often sufficient to move from one state to another.

Update:

Summary:

Trigger (event) is some new data (of any data type) that was received by the object.
Guard is boolean expression on some data that is alrady present in the object.

Trigger (event) is an outside event that some other actor fired - user has pressed a button, browser requested a page load, etc. So in the image above, every time user presses a digit on a digital lock it fires "pressed digit" event.

If the pin (sequence of digits) is valid, then the transition to unlocked state will be enabled.

Yet another way to look at it:

If you press a keyboard key the system fires a keypress event, that would be a trigger whose value is the pressed key. Then you can make a guard [pressedKey = enter] (guard is always a boolean expression).

However having just the guard is not enough here, because there would be nothing to compare against.