Skip to content

Commit e2c82be

Browse files
committed
Fix #77 - Added explanation about exception to rule G-5040 in case of proper use of Logger.
1 parent 9d2d2f5 commit e2c82be

File tree

1 file changed

+15
-0
lines changed
  • docs/4-language-usage/5-exception-handling

1 file changed

+15
-0
lines changed

docs/4-language-usage/5-exception-handling/g-5040.md

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,8 @@
77

88
There is not necessarily anything wrong with using `when others`, but it can cause you to "lose" error information unless your handler code is relatively sophisticated. Generally, you should use `when others` to grab any and every error only after you have thought about your executable section and decided that you are not able to trap any specific exceptions. If you know, on the other hand, that a certain exception might be raised, include a handler for that error. By declaring two different exception handlers, the code more clearly states what we expect to have happen and how we want to handle the errors. That makes it easier to maintain and enhance. We also avoid hard-coding error numbers in checks against `sqlcode`.
99

10+
When using a logging framework like Logger, consider making an exception to this rule and allow a `when others` even without other specific handlers, but *only* if the `when others` exception handler calls a logging procedure that saves the error stack (that otherwise is lost) and the last statement of the handler is `raise`.
11+
1012
## Example (bad)
1113

1214
``` sql
@@ -29,4 +31,17 @@ exception
2931
my_package.some_further_processing();
3032
end;
3133
/
34+
```
35+
36+
## Example (exception to the rule)
37+
38+
``` sql
39+
begin
40+
my_package.some_processing();
41+
exception
42+
when others then
43+
logger.log_error('Unhandled Exception');
44+
raise;
45+
end;
46+
/
3247
```

0 commit comments

Comments
 (0)