Try catch block I usually use in InterSystems ObjectScript

I often do this too, I think this sort of pattern is a good way to make the error handling simple and consistent.

I'm not really a fan of the status codes. They seem like a legacy item for the days prior to try/catches when traps were used. 

Having to maintain code to handle possible exceptions AND "errors" means more control flow to check and handle problems through the various levels of code.

Say that code above is within a method that's within another method that's called from the main part of the program. Now, you need three levels of try/catches. That's a lot of extra lines of code (code smell), lost errors and performance degradation.

Instead, I encourage my developers to use the fail fast methodgy. We use try/catches as high as possible in the code or when absolutely necessary, like when something is prone to exceptions but shouldn't stop the overall program from running. 

Status codes still have a place along side of Try/Catch in my opinion.  They really only serve to indicate the ending state of the method called.  This is not necessarily an error.  I agree that throwing an exception for truly fatal errors is the best and most efficient error handling method.  The issues is what does "truly fatal" mean?  There can be a lot of grey area to contend with.  There are methods where the calling program needs to determine the correct response.  For example take a method that calculates commission on a sale.   Clearly this is a serious problem on a Sales order.  However, it is less of an issue on a quotation.  In the case of the latter the process may simply desire to return an empty commissions structure.

Placement of try/catch blocks is a separate conversation.  Personally I find using try/catch blocks for error  handling to be clean and efficient.  The programs  are easier to read and any recovery can be consolidated in one place, either in or right after the catch.  I have found that any performance cost is unnoticeable in a typical transactional process.  It surely beats adding IF statements to handle to handle the flow.  For readability and maintainability I also dislike QUITing from a method or program in multiple places.  

So where is the "right" place for a try/catch?  If I had to pick one general rule I would say you should put the try/catch in anyplace where a meaningful recovery from the error/exception can be done and as close to the point where the error occurred as possible.   I the above example of a Commission calculation method I would not put a try/catch in the method itself since the method can not perform any real recovery.  However I would put one in the Sales order and Quotation code.

There are many methods to manage program flow under error/exception situations;  Try/Catch,  Quit and Continue in loops are a couple off the top of my head.  Used appropriately they can create code that is robust, readable and maintainable with little cost in performance.    

I agree with both Nic and Rich.

The issue with e.Log() is that it clutters up the error log with repetitive entries, each subsequent one with less detail than the prior. The same thing happens in Ensemble when errors bubble through the host jobs.

The trick here is knowing when to log an error verses when to just bubble it up. Using Nic's method we lose the context of the stack since the log isn't written until the entry method with the Try/Catch. Using your method we get noise in the logs, but at least the first one has the detail we'll need.

I believe the root problem here is re-throwing the status. An exception should represent something fatal and usually out of the applications control (e.g. FILEFULL) while a %Status is a call success indicator. To that end your code could be refactored to just Quit on an error instead of throwing it. That way a single log is generated in the method that triggered the exception and the stack is accurate.

However this doesn't work well in nested loops. In that case a Return would work unless there is a cleanup chore (e.g. releasing locks, closing transactions, etc). I haven't come up with a pattern for nested loops that doesn't clutter up the source with a bunch of extra $$$ISERR checks that are easily missed and lead to subtle bugs.

Personally I use your style without logging because:

• Every method uses the same control structure
• Works with nested loops without extra thought
• Can ignore errors by simply invoking with Do instead of $$$TOE/$$$ThrowOnError
• Cleanup code is easy to find or insert
• Using ByRef/Output parameters makes it trivial to refactor to return more than one value

I do lose the ability to see an accurate stack trace but most of the time the line reference in the error is enough for me to quickly debug an issue so it is an acceptable trade-off. Only in the most trivial methods is the Try/Catch skipped.

All that said Nic's style is a solid approach too. By removing a bunch of boilerplate Try/Catch code it lets the programmer focus on the logic and makes the codebase much easier on the eyes.

Well, I think a major question is: What do you use to return runtime information to your caller when you implement your own code? Do you return a %Status object, or something similar, or do you throw exceptions and don't return anything.

Most code snippets I have seen here make use of try/catch, but do return a status code itself. 

Personally, I prefer to use try/catch blocks and throw errors when I encounter issues at runtime. The try/catch philosophy is optimized for the case that everything goes well and exceptions are the, well, exception. Handling a status object is not as clean from a code maintenance perspective (more lines of code within your logic), but allows you to handle multiple different scenarios at once (it was okay/not okay, and this happened...)

Obviously, this is my personal preference.

Other than locks, there are a few other cases where cleanup may be needed whether or not something goes wrong:

• Closing SQL cursors that have been opened
• Ensuring that the right IO device is in use and/or returning to the previous IO redirection state.

There are probably more of these too.

Here's the convention we use for error handling, logging, and reporting in InSync (a large Caché-based application):

• We have TSTART/TCOMMIT/TROLLBACK in a try/catch block at the highest level (typically a ClassMethod in a CSP/Zen page). There isn't much business logic in here; it'll call a method in a different package.
• If anything goes wrong in the business logic, an exception is thrown. The classes with the business logic don't have their own try/catch blocks unless it's needed to close SQL cursors, etc. in event of an exception. After the cleanup is done, the exception is re-thrown. (Unfortunately, this means that cleanup code may be duplicated between the try and catch blocks, but there's typically not too much duplication.) The classes with business logic also don't have their own TSTART/TCOMMIT/TROLLBACK commands, unless the business logic is a batch process in which parts of the process may fail and be corrected later without impacting the whole thing; such a case may also call for a nested try/catch to do the TROLLBACK if something goes wrong in part of the batch. In this case the error is recorded rather than re-throwing the exception.
• We have our own type of exception (extending %Exception.AbstractException), and macros to create exceptions of this type from:
  • Error %Status codes
  • Error SQLCODEs and messages
    • SQLCODE = 100 can be treated as an error, "alert", or nothing.
  • Other types of exceptions
• Exceptions of our custom type can also be created to represent a general application error not related to one of those things, either a fatal error, or something the user can/should fix - e.g., invalid data or missing configuration.
• The macros for throwing these exceptions also allow the developer to provide a localizable user-friendly message to explain what went wrong.
• When an exception is caught in the top level try/catch (or perhaps in a nested try/catch in a batch process), we have a macro that logs the exception and turns it into a user-friendly error message. This might just be a general message, like "An internal error occurred (log ID _______)" - the user should never see <UNDEFINED>, SQLCODE -124: DETAILS ABOUT SOME TABLE, etc.
• Our persistent classes may include an XDATA block with localizable error messages corresponding foreign and unique keys in the class and types of violations of those keys. For %Status codes and SQLCODEs corresponding to foreign/unique key violations, the user-friendly error message is determined based on this metadata.
• Logging for these exceptions is configurable; for example, exceptions representing something the user can/should fix are not logged by default, because they're not an error in the application itself. Also, the log level is configurable - it might be all the gory detail from LOG^%ETN, or just the stack trace. Typically, verbose logging would only be enabled system-wide briefly for specific debugging tasks. For SQL errors, the SQL statement itself is logged if possible.

I thought this convention was too complicated when I first started working with it, but have come to see that it is very elegant. One possible downside is that it relies on a convention that any method in a particular package (InSyncCode, in our case) might throw an exception - if that isn't respected in the calling code, there's risk of a <THROW> error.

I mentioned the InSync approach previously on https://community.intersystems.com/post/message-error-csppage . Unfortunately, it's coupled with several parts of the application, so it'd be quite a bit of work to extract and publish the generally-applicable parts. I'd like to do that at some point though.