What? Why? Where? When? Which?
What? Why? Where? When? Which?
Rajeev Pedada wrote:Thanks for replying,
can I use like this...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
What? Why? Where? When? Which?
Rajeev Pedada wrote:Okay. I'm just trying to do things given by my superior. i.e Employee project(includes CURD operations with Database) and I'm stuck with DBService code in the Exception Handling. His requirements are...
Sounds reasonable, although I dispute the word "clean".1) To use Runtime Exceptions so that code is clean. (No need to declare in method signature or keep the calling method in try-catch block).
??? Displaying meaningful messages has NOTHING to do with using Custom exceptions, since ANY Exception can include a message.2) To use Custom Exceptions so that we can display meaningful exception messages to user.( like I specified fileName Not Found).
You'll have to explain that one to me, because I don't understand it at all.3) Not to use any subclasses of Exceptions( because no much action taken after catching a subclass Exception)
It mystifies me too. How is a message an "input"?4) Validating every Input in project including Exception message(This I don't understand properly ,so only I used ExceptionHandler).
Sounds perfectly reasonable. I do, however, assume that you log these messages somewhere.5) Not to use System.out.println() anywhere.
Not suppressing exceptions - fine.6) And other things like Not to supress an Exception, No hardcodedpath etc.
Well, if it was me, I'd invite my boss out for a quiet beer, and tell him (and I suspect it's a 'him') - in the politest possible way of course - that he's a [nasty word meaning "having no intelligence" deleted].So to achieve the above requirements , where should I start my journey?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Junilu Lacar wrote:Checking the exception message can be done as follows:
What? Why? Where? When? Which?
Dave Tolls wrote:
That falls into the trap I mentioned earlier.
If that's inside a catch block (whether directly or inside a "handler") you end up losing the root exception, for no better reason than your re-raising exception doesn't have a message. Something I would consider far less important than whatever it was that actually caused the code to go wrong in the first place...
Junilu Lacar wrote:These are "context free" rules, usually coming from the more "liberal" camp of the Checked vs Unchecked exception debate.
This debate usually arises when adopting the Spring Framework philosophy of preferring unchecked exceptions.
About the PHB thing, well, maybe. Or perhaps the guy is just handing down "traditional wisdom" and doesn't understand the reasons behind the prescriptions either, which would make him/her merely ill-informed at best.
The requirement to not use subclasses of Exception is really a corollary to "Prefer throwing runtime exceptions"
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Rajeev Pedada wrote:
4) Validating every Inputdata in the project including Exception messages.
What I think I need to do validation for statements like this
Rajeev Pedada wrote:
6) No hardcoded path
I meant , Not use statemnts like this C:\Users\Iteam1\Desktop\Rajeev\hr\res\dbconfig.properties because when run on different machine, its error prone.
Winston Gutkowski wrote:
Junilu Lacar wrote:These are "context free" rules, usually coming from the more "liberal" camp of the Checked vs Unchecked exception debate.
Could you elaborate?
Rajeev Pedada wrote:@Winston
3) Not to use any subclasses of Exceptions...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
And the reason why nobody likes them (IMO) is because the ones we run into 99% of the time - IOException and SQLException (both of which are hierarchies) - should never have been made checked exceptions in the first place.
Junilu Lacar wrote:A lot of people already have: Spring Framework Checked vs Unchecked Exceptions
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Rajeev Pedada wrote:@Winston
3) Not to use any subclasses of Exceptions( because no much action taken after catching a subclass Exception)
...
[/code]Better to go with:
[code=java]catch(Exception e){
throw new DBException(e);}[/code]
4) Validating every Inputdata in the project including Exception messages.
What I think I need to do validation for statements like this [code=java]throw new DBException(null);[/code]
6) No hardcoded path
I meant , Not use statemnts like this C:\Users\Iteam1\Desktop\Rajeev\hr\res\dbconfig.properties because when run on different machine, its error prone.
Anyways, I have two more discussions left with him. I will again come with my queries.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:Ooof. NO. That catches any Exception and equates it to a DBException, which is simply transferring the problem.
Winston Gutkowski wrote:
Ideally, database subsystems would use two hierarchies - SQLException (checked) to indicate a "data" or syntax error, and SQLError (unchecked) to indicate any type of connection issue between you and the database.
But they don't (or at least most of them don't) - and unfortunately that's what you're stuck with.