Catching exceptions in code

See more

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.

Scope (details): a managed application, an ordinary application.

3.1. If there is a server business logic called from the client upon user interactive actions:

&AtServer
Procedure ExecuteOperation()
    // Code that throws an exception
    ....
EndProcedure

It is incorrect to hide the issue from the user and administrator:

// On the client
Try
    ExecuteOperation();
Exception
    ShowMessageBox(,NStr("en = 'Cannot execute the operation.'"));
EndTry;

It is correct to write a detailed exception presentation to the event log and add a short presentation to the user message:

&AtServer
Procedure ExecuteOperation()
  Try
    // Code that throws an exception
    ....
  Exception
    // Writing an event to the event log for the system administrator.
    WriteLogEvent(NStr("en = 'Executing an operation'"),
       EventLogLevel.Error,,,
       DetailErrorDescription(ErrorInfo()));
    Raise;
  EndTry;
EndProcedure

 

On the client:

Try
    ExecuteOperation();
Exception
    MessageText= BriefErrorDescription(ErrorInfo());
    ShowMessageBox(,NStr("en = "The operation cannot be executed due to:") + Chars.LF + MessageText);
EndTry;

 

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.
For example:

Try
    LoadFileFromInternet(...);
Exception
    MessageText= BriefErrorDescription(ErrorInfo());
    MessageText= NStr("en = "Cannot load the file:'") + Chars.LF + MessageText + Chars.LF + NStr("en = "Possible reasons:
• No Internet connection;
• Web site issues;
• Firewall or other middleware (antivirus software) blocks the application attempts to connect to the Internet;
• Internet connection is established via proxy, but its parameters are not specified in the application.'");
    ShowMessageBox(,MessageText);
EndTry;

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(...);
If ErrorCode= 12345,
...
ElseIf ...

It is correct to use string literals (for example, "Successfully", "NoSpace", "Canceled", and other):

ImportResult= LoadFileFromInternet(...);
If ImportResult= "Successfully" Then
...
ElseIf ...

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
Procedure CreateFileOnHardDrive()
    // Code that throws an exception
    ....
EndProcedure

We recommend that you make an additional server call to record a failed operation in the event log:

Try
    // Client code that throws an exception
    CreateFileOnHardDrive();
Exception
    MessageText= BriefErrorDescription(ErrorInfo());
    ShowMessageBox(,NStr("en = "The operation cannot be executed due to:") + Chars.LF + MessageText);
    WriteFileHandlingError(DetailErrorDescription(ErrorInfo())));
EndTry;

&AtServerNoContext
Procedure WriteFileHandlingError(...)
    WriteLogEvent(NStr("en = 'Executing an operation'"),
       EventLogLevel.Error,,,
       DetailErrorDescription);
EndProcedure

3.4. No exceptions can be caught without notifying the system administrator:

Try
    // Code that throws an exception
    ....
Exception // Catching exceptions
EndTry;

Generally, such clause hides a real issue, which cannot be diagnosed later.
Correct:

Try
    // Code that throws an exception
    ....
Exception
    // Explanation of reasons to catch all exceptions without warning users.
    // ....
    // An event is written to the event log for the system administrator.
    WriteLogEvent(NStr("en = 'Executing an operation'"),
       EventLogLevel.Error,,,
       DetailErrorDescription(ErrorInfo()));
EndTry;

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);