Colleague asked me for general advice/arguments for exception handling with Try::Tiny .

Policy so far was to return complicated error codes in a C style.

Told him that I'm not aware of a general best approach, while I like catching errors, there are too many different use cases.

For instance one of my styles for handling simple routines is to write

sub complicated_flow {
    ... 

    my ($res1,$res2, ...) = routine()  
        or  return;                       # ERROR  skips rest 

    ...
}

sub routine {
    …
    return if (ERROR);
    ...
    return 1,2,3;
}
[download]

Please note that because of the list assignment (@result) = on the LHS the or will only fire in case of a blank return. (the list assignment returns the number of assigned values and 0 is false)

This doesn't exclude catching internal errors with try/catch aka eval BLOCK but is more concise for simple cases and follows the " open ... or ERROR " modell.

Are there best practices listing the cases where throwing an error message via die is more appropriate?

update meditation

• I think the distinction between internal errors and "messages" matters here.
• It also matters if I need to know the reason for the error at run-time or if post mortem is enough.