Should failed operations (e.g. deadlocks) be marked reject or Debug.trap? Please give examples of using both.
Is it true that Debug.trap is intended only for catching errors in code (not input errors or for example overload of the system)?
As Debug.trap rollbacks unlike reject, isn’t it wise to use it for any situation that needs rollback, not only for indicating coding errors? Why was reject chosen by language designers not to rollback?
I guess it depends on your needs. Does you application work better if you roll back or not?
I think, it works better if I rollback. (I am still however a novice in IC development.)
I am also looking for a “formula” for what the correct behaviour in case of failed operations is, but couldn’t find one yet. (See my related question Is trapping better than returning an error?)
I think you are free to choose between trap and reject, depending on whether you want to roll back or not. The handling on the caller side is essentially the same. The caller sees an error code and an error message (Text). I don’t think trap is reserved for certain situations.
That said, even in error cases it could be that you do not want to roll back, even if you normally would. For example, a canister might want to track who (which caller) made the failed call because the canister might still want to charge a fee for the call.