That helps a lot. Thank you. I will remember these guidelines when I am deciding between error and exception.
Ok, so before I answer let me start by warning you - this is a huge topic, with more contention than which is the better editor; emacs or vim. Consequently, all I'm offering you here is my (and one) view on this subject. It's very much flavoured by my personal experience, and my own coding style.
Caveat over, here's my rule.
I use an exception when it's the sort of error that the immediate caller is unlikely to want to deal with. I use an error (eg. returning false or nil) where the caller is going to deal with it directly. This doesn't mean that the caller can't deal with it if they want to, they can, but the question is whether they're likely to want to deal with it.
So, your directory situation. You might have a logging object, the caller of a logging method is NEVER going to want to handle the situation where the directory is unavailable for writing the logfile to - no one wants a whole heap of code surrounding each log call to create a new directory, so that's a perfect example where I'd use an exception.
Hope that helps.
Thanks. I will implement the error handling mechanism with Error class in lib folder as you have suggested.
How do I go about deciding whether they are errors or exceptions? For example, I want to handle a situation where the directory to which we are trying to write, does not exist or does not have write permissions. Is this an error or an exception?
Whether to have these as errors or exceptions is a question of architecture and design. You haven't given much to go on (and others may disagree) but it sounds like these are very much errors, and not exceptions.
Just create an error class, put it in your lib dir, you can either put the mapping between error codes and messages in an YML file or just stick them in a class attribute (hash) in this error class. You can then either mix this error class into the controller that you want the functionality in, or just call it explicitly. Make the class you have return instances of this error class, like @return MyError.new("E400")@ instead of just the string, and then in the controller you can check the return with @.kind_of?@ or @.respond_to?@ and output the error code. A nice solution is to define the @to_s@ method yourself and return the error string in that, so then you can just use your error object in a string context and it will return the error string.
Currently, I have a few methods in Ruby class (not a model) which returns a string of error/warning codes in case of errors. Example, return "E400,W200,E510" This class is called from the Controller. Every time the Controller calls a method, it checks the return error codes - if there is an error starting with E, in this error codes string, it stops further processing, sets flash[:error] and flash[:notice] and redirects to error page. Also, the error message for a particular error code comes from a .rb file. I think I have completely messed up the error handling in my application. I am sure the Rails experts here will agree with me.
After some browsing, I got a few ideas that I think I could implement. 1. I could use a yml file for storing error messages corresponding to error code. 2. I could use rescue_from in the controller in combination with custom exceptions.
I am not sure how to go from here. Should I be using begin recue end blocks? When should we use rescue_from? How do I get error messages from yml file?