I have a Query i have been asked in an Interview like what is the exception handling framework used my project,but we actually did not use any framework ,we used just normal try catch and throws,so can anyone please tell me what is the exception handling framework,when i browsed through net i found something like JEHA,so is there any other framework available.
srikanth darbha wrote:I have a Query i have been asked in an Interview like what is the exception handling framework used my project,but we actually did not use any framework ,we used just normal try catch and throws,so can anyone please tell me what is the exception handling framework,when i browsed through net i found something like JEHA,so is there any other framework available.
I'm with Tim - not quite sure what they were getting at.
My general approach, though, is: Fail FAST, and fail LOUD; and that's generally achieved by a minimalist approach.
Getting into "frameworks" (unless they're very well designed and consistent in their approach) tends to lead to two problems:
1. You don't "see" an error until it's too late to do anything about it.
2. You fight Java's natural urge to inform you about an error when it occurs, which is when you'll get most use out of a stacktrace.
Unfortunately, it's not what "employers" want to hear - and you can understand their point of view. Who wants to go onto a website and get a 404 error? It doesn't mean anything to you, as a user, so why should you have to deal with it?
My counter, as a programmer, is that it means that something is wrong; and therefore the user should NOT be allowed to continue, whether they like it or not.
And trust me, there's nothing that'll get a company that have "rushed" a website into production too quickly into "fix it" mode quicker than a bunch of 404s.
So boss, what do you want me to spend my time doing? Writing a pile of "noise" code to prevent a user from EVER seeing an error message; or finding out WHY they got it in the first place? You can't have both; and the first will often work against the second.
That said, there's another good paradigm to follow: An ounce of prevention is worth a pound of cure.
So: Program defensively.
Don't allow errors to happen.
Think ahead of the runtime.
Never allow methods to return null unless you intend to do something with that information. And if you do, document it in bold type.
But if something DOES happen, find out about it immediately - even if it means displaying an error message.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
I can probably through some light on what the interviewer *MIGHT* be looking for. Framework and Exception is loosely used term which causes more confusion in interviews than it helps.
In an usual Java app there is a backend and GUI. And I would guess its same for srikanth. Backend could be anything from an App server, Web Services or a Database. GUI could be a Spring app, Web app etc. Interviewer was trying to ask, how would transfer error messages (Exceptions) from backend to UI and display to User.
This based on my encounters with *Some* Interviewers and I might be absolutely wrong here.