An alternative to salvation in Ruby?

Question

It seems that I have begin ... rescue ... end sentences everywhere in my code! This does not seem to be the right thing.

Can anyone suggest how I can catch some exceptions without putting everything inside begin ... rescue ... end ? Any way to just tell Ruby to shut up and keep going, even if an exception occurs?

Answer 1

As in other languages, for any non-trivial program you really need a well-designed architecture for handling exceptions. One approach is to define exception handling areas in your project, and then you usually want to catch (save) exceptions within the scope of the area. There is a compromise. The closer you are to the stack where the exception occurred, the more contextual information about the state that caused it. If you try to be too granular, you will encounter the problems that you described. On the other hand, if you only catch exceptions at the top of the stack (in "main"), then there is no context. Therefore, identifying areas for handling exceptions involves evaluating this trade-off in relation to your specific program or system.

Ruby gives us the option to "try again" - not available in some other languages. This should be used sparingly! But where it makes sense (for example, while waiting for a network or resource to free), such exceptions should be handled very locally.

Otherwise, I tend to define exclusion areas at a fairly coarse-grained level in a large project. It is often useful to catch some contextual information, since the exception bubbles from the point of occurrence across the various boundaries of the scope. To help with this, you can expand the hierarchy of Ruby exception classes by specifying some of your own application-specific exception types, but again there are trade-offs. Your project should have clear standards on when to use custom exception types against capturing contextual data in the message field, what information the message field should contain, etc., As well as a strategy for cataloging the messages that your code can generate.

In most cases, exceptions are allowed to propagate up to the centralized handler, register (for the technical team and support), generate useful error messages for the user, and determine if this condition is sufficient for your program to exit. Generally, all exceptions should be handled inside your code or within the application that you are using. No exceptions should be allowed to exclude the default exception handling for the execution language or OS.

These are my thoughts, based mainly on experience with other languages, but I think they apply in general. Bottom line, in a large project, you need to put a lot of effort into developing exception handling compared to the special approach.

Answer 2

 def action yield rescue .... ensure .... end action { stuff_goes_here } 

Answer 3

One thing that can make it look a little cleaner is salvation at the end of the method, so you don’t have to start another level of indentation:

 def get_file_prompt print "Enter file name: " return File.open(read) rescue StandardError puts "File could not be opened" return nil end 

Answer 4

Oh no. The whole point of exceptions is that they are conditions that need to be handled.

Think of it this way: Exceptions are your friends! Without them, you will have to write a lot of boring statements that are difficult to read and maintain.

If you are learning Ruby (or any language with an exception system), considering exceptions is one of the most important aspects, and you would take a good time to figure out how to handle them, raise them, and when you can ignore them.