I agree with the premise, but I wonder if it's too general. In any language, it's usually wise to avoid directly exposing users to errors in the underlying framework.

I agree with the premise, but I wonder if it's too general. In any language, it's usually wise to avoid directly exposing users to errors in the underlying framework.

Yes, but the explicit warning is not present in the code, StandarError. In the specific case of Rails, it would be good to have this warning explicitly included to promote this good practice.

Hi @andyw8 Could you help me understand how you would suggest implementing this change? Would you suggest making the change in a different location, or perhaps adding more explanation to the proposal?"

What is wrong with the following approach?
What I'm trying to do is to take the focus off StandardError class itself.

begin
 raise StandardError.new("No access")
rescue => e
 @message = e.message
 render :error
end

There certainly are cases when advanced handling is needed, and there's even a whole Exceptional Ruby book about this.
But what is the problem for the basic case?

What is wrong with the following approach?
What I'm trying to do is to take the focus off StandardError class itself.

begin
 raise StandardError.new("No access")
rescue => e
 @message = e.message
 render :error
end

There certainly are cases when advanced handling is needed, and there's even a whole Exceptional Ruby book about this.
But what is the problem for the basic case?

In this particular case, the current implementation of the code is appropriate. However, in more complex applications or broader contexts, it is important to consider which parts of the code would benefit from specific error handling. That's why I suggested adding it to the Controllers, where vulnerabilities are more likely. What do you think? Do you agree with this proposal or do you have another suggestion for where to implement this change?

@pirj