Scope: managed applications, mobile applications, and ordinary applications.
1. In most cases, it is not recommended to catch exceptions. Specifically, do not catch exceptions only to show error messages to users. Users are shown the error message even for unhandled exceptions. If an exception is thrown on server, the exception details are also written to the administrator's event log.
2. However, there are cases when you need to catch exceptions. For example, when you need to complement an error message with some details to make it more meaningful and clear to the user. You need to record an error cause in the event log to allow the system administrator to diagnose the issue and notify the technical support if required.
We recommend that you write a detailed exception presentation to the event log and add a short presentation to a user message.
3. Special cases of incorrect use and catching of exceptions.
3.1. If there is a server business logic called from the client upon user interactive actions: &AtServer It is incorrect to hide the issue from the user and administrator: // On the client It is correct to write a detailed exception presentation to the event log and add a short presentation to the user message: &AtServer
On the client: Try
3.2. Do not analyze exception texts to interpret error causes. The exception text can vary depending on localization. If standard functionality is unavailable (for example, standard exceptions), display exception texts to users "as is". To make them clearer, provide possible causes. Try If analysis of exception types is critical for correct business logic, do not use exceptions and use error (return) codes. Do not use numeric codes of errors as the code becomes unreadable: ErrorCode= LoadFileFromInternet(...); It is correct to use string literals (for example, "Successfully", "NoSpace", "Canceled", and other): ImportResult= LoadFileFromInternet(...); String literals of error codes are not localized. Exceptions are web services and other external systems, in which error codes are unavailable and operation results are translated into the calling code of application configurations as exceptions. 3.3. If a client business logic exists (a code is executed on the client): &AtClient We recommend that you make an additional server call to record a failed operation in the event log: Try &AtServerNoContext 3.4. No exceptions can be caught without notifying the system administrator: Try Generally, such clause hides a real issue, which cannot be diagnosed later. Try See also Access to the file system from configuration code, deleting temporary files. |
3.5. Do not use exceptions to check objects for attributes, methods, or templates. This makes it harder to trace errors and to debug applications with "Stop on error" mode enabled.
Instead of catching exceptions, adopt one of the following practices:
- Use tools that allow to explicitly check objects for required attributes, methods, or templates.
- For libraries, specify all aspects of integration in the overridable modules (see Overridable and built-in objects).
- Reconsider the behavior of methods that catch exceptions. For example, you can add parameters that determine whether a method or object property must be called.
Incorrect:
Try
ContextEDIServer.GetTemplate("ExchangeAddIn");
AddInPath = ContextEDIServer.ObjectPath + ".Template.ExchangeAddIn";
Exception
EndTry;
Correct:
ExchangeAddInTemplate = ContextEDIServer.Metadata().Templates.Find("ExchangeAddIn");
If ExchangeAddInTemplate <> Undefined Then
PathToTemplate = ExchangeAddIn.FullName()
EndIf;
3.6. For handling exceptions in transactions, see Transaction rules.
3.7. Do not use exceptions to convert a value to a type. Use TypesDetails instead.
Incorrect:
Try
PermissionDaysCount = Number(Value);
Exception
PermissionDaysCount = 0; // Default value
EndTry;
Correct:
TypeDetails = New TypesDetails("Number");
PermissionDaysCount = TypeDetails.AdjustValue(Value);