Just wondering how people dealt with exception messages? Apart from those displayed to user, what did people do with the rest? Is one required to use the Java.util.Logger class to log messages? If 1 is required to use the logger api, where are the files written out to? Is a new folder created for this? How would an examiner know whether a method, example "create" works or not? Does 1 write to console? Would appreciate ideas.
It is not mentioned that you are required to use a Logger class to log messages. In my approach I have chosen to notify the user for all the exception thrown. I have created an ExceptionHandler class and all exceptions are passed to it. It's main purpose is to filter the exception and display the apropriate message. If the exception message does not match any of the predefined exceptions then a generic message is prompt to the user that the application has failed to process the request with main body text the Exception.getMessage().
I'm explaining the reason I've chosen this approach in the following example:
Client changes record fields and performs an update. The record passes all the logical rules that check the record for dublication, locked, etc.. When it comes to flushing the changes back to the db file suppose that an unexpected error occurs. The client should be aware that the record has not been updated in order to take actions.
Of course you can have a logger class for the developers to track the message errors but in either case the client must be aware that the actios was terminated unseccessfull. Whatever option you choose with a strong justification in your choices.txt you will not have a problem. It will be then in the assessors judgement how many credits they will allocate for your aproach.
The exceptions thrown in my business service (no room found, room already booked, remote exception,...) are caught in my GUI and an appropriate (human understandable) message is shown to the user.
Because logging was not a requirement I don't log any exception to the log. I used a logger, but just for debugging purpose: at the beginning and end of each method I log parameters or return value. This logger outputs to the console (not a file, because it solves issues as where to put it, what if directory/file can't be created,...) and logger was turned off when I submitted my assignment
Thanks for the replies. I understand the exception handling at the front and displaying message to user and that's ok. What would be the situation with the following, for example, In my update method of the Data.java class, I check the elements of the passed array. If any of the elements are greater than the size they should be, I throw an IllegalArgumentException. I am currently doing the network testing. So if I try to book a room with an array concerning the problem I have stated, I currently get an illegalArgumentException and therefore one cannot perform this booking.
Firstly, I persume we must respect the interface, so mine just has 2 exceptions thrown, "RecordNotFoundException" and "SecurityException" for update, is it ok to throw this illegalArgumentException all the way through the network to the person who is accessing the network functionality? I am persuming the 3 tiers, client, network and server have to be tested individually.
Secondly, what would I do with the exception if it is? Clearly, the person has not made the booking here.
Joined: Sep 09, 2009
I believe that you shouldn't allow to pass information over the network if these are not valid. It costs to make a network call with invalid data. At my approach i'm informing the user that the specified values exceed the maximum width and i'm asking the user if he/she still wants to proceed, informing the user that if he/she proceeds the values will be trimmed to the maximum width per field. To achieve this I have chosen not work with an array object between the client and the server. The client is aware of a Hotel bean that has getters and setters for the values of the dbSchema. The Hotel object is transated to an array object once it reaches the server and whatever values it has the Data.class will ensure that the correct width per field will be flushed to the db file. As a result no exception will be thrown to the client, unless an unexpected error occurs as I stated in my first post.
At any case if the update or any other operation fails the user must be informed in order to avoid confusion and presenting missleading data to the front-end
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com