Raising an an exception: string vs custom class

Question

Is there any advantage to do:

ApiTokenExpired = Class.new(StandardError)
...
raise ApiTokenExpired if response.errorCode == 429

over this lazier alternative:

raise 'api token expired' if response.errorCode == 429

considering that this error detection happens only once in the code?

sschmeck · Accepted Answer · 2016-01-25T08:18:00.390

3

There is an important advantage of custom errors like ApiTokenExpired if you have to handle the error in an specific way somewhere in the call stack.

begin
  # ...
rescue ApiTokenExpired => error
  # handle the specific error
rescue => error
  # default error handling 
end

IMO the decision to create custom errors doesn't depend on the size of the project or future maintenance.

Since custom error classes cause an extra effort I don't use it by default. When a special error handling is needed then an error class should be introduced.

edited Jan 25 '16 at 08:18

answered Jan 08 '16 at 21:34

sschmeck

7,233
4
40
67

Not sure I understand your last sentence. Do you mean that you would use custom errors most of the time, because the overhead is negligible? – Jerome Dalbert Jan 24 '16 at 07:25
@JeromeDalbert I do not use custom error classes by default. When I need a specific error handling then I use this approach. A custom error class has an overhead that should be justified. – sschmeck Jan 25 '16 at 07:18
@JeromeDalbert I adapted my explaination in the answer. Hope, it is clearer now. – sschmeck Jan 25 '16 at 08:18
Thanks, I am much more satisfied with this answer. YAGNI – Jerome Dalbert Jan 25 '16 at 08:23

score 1 · Answer 2 · answered Jan 08 '16 at 19:48

With the first one, you can selectively rescue that error by the class when that code is embedded in larger software. You can still do that with the second one using pattern match with the error message string, but in general, you might alter the message format over time due to refactoring (as opposed to unlikelihood of changing the exception class with your first form), and there can also be different exceptions that have a similar message string, both of which can break pattern matching. When you consider future maintenance, the first one is better.

score 1 · Answer 3 · answered Jan 08 '16 at 19:50

It does if your app is designed to have error handling or plan to in the future(I mean, any successfull system will want that one day, right?), the only thing you can do with a string is read it in a log or display it in an error message, with types you can code all sorts of things in a decoupled fashion.

For example, ApiTokenExpired could maybe be handled with "try again" response since it's an external problem or be handled by the steps necessary to renew the API Token(and if you used a Typed Exception, you can plug it in later!), maybe you want all errors that are considered SEVERE or UNEXPECTED to send the system administrator an e-mail and also store statistics on the frequency of the error, typed exceptions allows you to code in anything you want in terms of what to do when your system is misbehaving.

Raising an an exception: string vs custom class

3 Answers3