• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is using ExceptionalHandler a good practice?

 
Ranch Hand
Posts: 75
Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's my code
DBService.java

ExceptionalHandler.java

DBException.java

I'm using Exceptional handler for validating input.
Should Custom Exceptions are called from Exceptional Handlers?
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frankly, that design is quite pointless and it leads to code that's misleading.

First, since your usage of it ensures that the parameter s is never going to be null, then you're always going to throw a DBException.

Next, if you designed the handler for inheritance, which is unlikely, based on your previous posts, then you have no control over what kind of exception will get thrown by other implementations so now your exception handling code becomes more obscure rather than clearer.

Lastly, if for some reason the handle method does get passed a null reference, then the handle method doesn't do anything which is misleading because you'd expect a method that's called "handle" to actually do something to handle the exception and not just quietly eat it.
 
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't see the point in it.
For starters, as written you are losing the original exception.
Secondly, it's more lines for no gain (in my opinion).
 
Rajeev Srikhar
Ranch Hand
Posts: 75
Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for replying,
can I use like this:-







okay, I want to know a basic concept which is not from Exceptional handling i.e If I implement an Interface like I did above in code, can i say that I'm following Inheritence?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not really anything happening there related to inheritance, more like just abstraction at the cost of clarity, which is the opposite of what abstraction is intended to achieve. The problem is that there's no logical connection between handling an exception, which is ostensibly what an ExceptionHandler would be about, and throwing a DBException specifically, which is what your implementation does. There's some cognitive dissonance there and Until you close that gap, anything you do around this design is going to be just a lot of pointless flailing about.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your design implementation hints more strongly at the name DBExceptionThrower rather than Handler but it still would be a pretty pointless class that only appears to be useful but in reality, isn't.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rajeev Pedada wrote:Thanks for replying,
can I use like this...


Rajeev. Let's get back to basics:

WHAT are you trying to do?

What you're doing right now is showing us a bunch of possible implementations for something we (or at least I) have no idea:
(a) What it's trying to achieve.
(b) Whether it's even required.

So if you tell us your goal, maybe we can advise you better.

Winston
 
Rajeev Srikhar
Ranch Hand
Posts: 75
Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
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).
2) To use Custom Exceptions so that we can display meaningful exception messages to user.( like I specified fileName Not Found).
3) Not to use any subclasses of Exceptions( because no much action taken after catching a subclass Exception)
4) Validating every Input in project including Exception message(This I don't understand properly ,so only I used ExceptionHandler).
5) Not to use System.out.println() anywhere.
6) And other things like Not to supress an Exception, No hardcodedpath etc.

So to achieve the above requirements , where should I start my journey?

--Thanks
-Rajeev
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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...


OK. Now it's getting clearer. This is a PHB problem.

Let me tackle the requirements one by one because that, at least, may give you some "ammunition":

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).

Sounds reasonable, although I dispute the word "clean".

2) To use Custom Exceptions so that we can display meaningful exception messages to user.( like I specified fileName Not Found).

??? Displaying meaningful messages has NOTHING to do with using Custom exceptions, since ANY Exception can include a message.

3) Not to use any subclasses of Exceptions( because no much action taken after catching a subclass Exception)

You'll have to explain that one to me, because I don't understand it at all.

4) Validating every Input in project including Exception message(This I don't understand properly ,so only I used ExceptionHandler).

It mystifies me too. How is a message an "input"?

5) Not to use System.out.println() anywhere.

Sounds perfectly reasonable. I do, however, assume that you log these messages somewhere.

6) And other things like Not to supress an Exception, No hardcodedpath etc.

Not suppressing exceptions - fine.
No hardcodepath - explain please.

So to achieve the above requirements , where should I start my journey?

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].

He's paying you good money to be a programmer, yet he's telling you not only what to do, but how to do it ... Why not just hire a typist?
Furthermore, he's requiring you to add a whole new (and possibly error-prone) layer to an existing application, simply to avoid having to deal with messages produced by an existing database product - which has presumably documented the ones they produce.

And who do you think is likely to get the blame if all this ends up in a steaming pile?


However, all joking aside, I would try to find out why this is needed, because it sounds like "noise code" to me (and you can quote me).

And FYI, the simplest "exception handler" of the type that you describe is:
HIH

Winston
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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. If you search for articles written about this, then you'll find some pretty compelling arguments. Honestly, I'm in the liberal Unchecked exception camp myself.

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" and should be restated as "Likewise, avoid throwing checked exceptions"

Most of the other "requirements" follow from this.

Checking the exception message can be done as follows:

 
Dave Tolls
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:Checking the exception message can be done as follows:



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...
 
Rajeev Srikhar
Ranch Hand
Posts: 75
Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Winston
3) Not to use any subclasses of Exceptions( because no much action taken after catching a subclass Exception)

I meant that Instead of using subclasses of Exceptions and throwing the same like below:
Better to go with:


4) Validating every Inputdata in the project including Exception messages.
What I think I need to do validation for statements like this

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.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The "no hard-coded path" probably refers to the brittleness of hard-coded package names in exception messages. So,

 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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...


Good catch and good point.

These kinds of checks are superfluous, IMO, if the programmer tests often and thoroughly because they would see "null" instead of a meaningful error message in the log. It's easy enough to fix though:

But again, I don't really see that there's any point in writing this kind of code so if it were me, I'd just ignore this "rule" and argue for its removal from the books.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?

This debate usually arises when adopting the Spring Framework philosophy of preferring unchecked exceptions.


Which we can certainly debate, but if my first experience of a Spring website is anything to go by, I'm not impressed, because it just froze my system (literally just now).

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.


And if he was simply ill-informed, that'd be fine; but he's not (unless I've read this thread entirely wrong). He's requiring that Rajeev do it the way he tells him to.

The requirement to not use subclasses of Exception is really a corollary to "Prefer throwing runtime exceptions"


OK, so let's deal with the elephant in the room - Checked exceptions.

Personally, I like them and, for an application designed from the ground up to use them, I think they're wonderful.

What they are NOT good for is I/O - of any kind, including databases - since an I/O or database subsystem cannot possibly know what your application needs to do in the event of an exception thrown by it.

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.

My 2¢.

Winston
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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


The "fix" here is to take the programmer who wrote that behind the woodshed and make an example of him/her on how NOT to write code... You guys are allowed to talk to each other at least, right? Sheesh, not everything needs to be addressed by "rules" and code.

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.


For once, a good rule. This is why there are variables in programming languages. At the very least, you should use a relative path instead of an absolute one.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?


A lot of people already have: Spring Framework Checked vs Unchecked Exceptions

Edit: If you meant to ask about the "context-free rule" part, it simply refers to a prescriptive set of rules that are given to enable people to accomplish something without necessarily being an expert. For example, a recipe is a set of context-free rules that allow you to cook a delicious dish even if you've never done it before. Chefs, on the other hand, don't need context-free rules. They use their experience and skill (their context) to produce culinary delights.

In programming, a context-free rule would be something like "Declare variables as List<whatever> rather than ArrayList<whatever>".

A relatively inexperienced programmer can write a good line of code (at least) by following this rule even if he/she doesn't fully understand the reasons for doing so.

We experienced programmers know that it goes back to "Prefer programming to abstractions rather than concretions" and the Liskov Substitution Principle. We have a deeper understanding of the context of the "List vs ArrayList" rule so we don't really need to think about it. We just do it.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rajeev Pedada wrote:@Winston
3) Not to use any subclasses of Exceptions...


Thanks for that. Let me look them over and come up with a reply.

Hope the other intra-moderator babble isn't distracting you, but sometimes we like to "discuss" interesting stuff like this.

Winston
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


Bullseye.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:A lot of people already have: Spring Framework Checked vs Unchecked Exceptions


No. Been there, done that.

I was more interested in your phrase "context-free rules", and specifically, how it applies here.

Winston
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wrote a few blog articles about how instruction on computer programming nowadays appears to have devolved into mainly context-free exercises that leave students dazed and confused. Just look around in the Beginning Java and JiG on any given day to see examples of people who were given context-free instructions. Many of the "problems" they're given to solve aren't really problems but rather templates that they simply need to fill in with syntactically correct code although not necessarily semantically meaningful in the context of any real-world problem. Because they lack context and a deeper understanding of WHY they are doing certain things, they end up with poorly-written and poorly-designed programs and very little progress to show for it in terms of truly understanding the CRAFT of computer programming. As shown in OP's responses, this has extended to the workplace and so-called "professional" development. For me, this is the root of all evil code.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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]


Ooof. NO. That catches any Exception and equates it to a DBException, which is simply transferring the problem.

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]


Ooookay. So how do you plan to do this from inside an "exception handler"?

The problem here is that exceptions can be thrown for all sorts of reasons; and the best way to provide context is to pre-empt them. Unfortunately, in a database situation, they can happen for any number of reasons.

For example, an INSERT might fail:
1. Because the row I'm trying to insert already exists (a classic "checked exception" context).
2. Because the connection was lost or closed, or the network is down, or the server in down, or any number of other "connection" issues that you have no control over.
But because the database has no idea what the context is to your system, the only thing it can do is give you is an SQLException - which is checked.

It also highlights a weakness of the checked/unchecked hierarchy, which is precisely that it IS a hierarchy; An Exception is either "checked" or "unchecked", and once you've chosen your poison, you can't create a subclass that reverses it.

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.

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.


I'm not quite sure what this has to do with your question, but has you boss not heard of jars? They, along with wars and ears, are the standard method of deploying Java programs; and they ARE a filesystem in all but name.

Specifically, they are an archive of ALL the files and directories required for your program to work, including any properties, local databases, libraries, or anything else that's needed; so they WILL work wherever they're deployed without any need for "hard-coding".

Anyways, I have two more discussions left with him. I will again come with my queries.


Best of luck.

Winston
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:Ooof. NO. That catches any Exception and equates it to a DBException, which is simply transferring the problem.


Agree, this is not good. This is an example of how a context-free rule can go seriously off course and people losing sight of the original intent.

This code is closer to the original intent of the "throw unchecked instead of checked exceptions" rule:

Here, the code in the associated try block should only cause a SQLException if a specific query failed. Since a SQLException doesn't mean much to higher-level code, it is wrapped in a more meaningfully-named runtime exception with the assumption that at some point it will be handled where it is most relevant as an "employee not found" error condition.

Over time, unfortunately, this context fades away into obscurity and the reasons for writing this code become less understood by new programmers coming into the code base. Eventually, the code is seen to fit the "pattern" of a simpler but more general rule to "wrap a checked exception in a runtime exception and rethrow it" and that's where you see the start of cargo-cult programming practices.

Edit: Notice how just a little refactoring and specificity can actually bring the "bad" code back into a "good" state. Those two catch blocks are very similar to each other and an astute programmer who understands the context of the "throw unchecked exceptions" rule can easily see that all you need to do to make the code make more sense is to change Exception to the more specific SQLException and rename or replace DBException with a more specific and better-named runtime exception like EmployeeNotFoundException.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
More on specificity...

Sometimes SQLException is not specific enough since there could be multiple reasons for a single query to fail. In that case, you can check the error code to decide which runtime exception to throw.

The first exception would bubble up to be handled by a service or domain object. The second exception would get bubbled all the way up to a general exception handling routine that would inform the application development team that there's a bug somewhere that was causing a data integrity issue. The default exception is just a catch-all that again would be handled by the general exception handling routine so the development support team can look further into what could have caused it.
 
Dave Tolls
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Hibernate, of course, goes completely the other direction.
Everything is a RuntimeException.
Gavin had the right idea of moving into a better hierarchy, but was also very much a proponent of unchecked, so Hibernate followed suit.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I look at it kind of like the way I see posted speed limits. In a community or near a school, I agree in posting 20 MPH speed limit signs. These SHOULD be strictly followed and enforced. On busy highways and near construction zones, 35/45/55 MPH speed limit signs SHOULD be strictly followed and enforced. On an open highway, however, I think the Germans got it right with their approach to speed limits on the autobahn. Of course, there's always a few a**holes who screw up and make that option unacceptable for everyone else so I guess it all depends on the a**hole density in your area whether or not "rules" are strictly adhered to or are used as just guidelines. Same thing goes with checked exceptions -- it's safer to have these when there's a greater propensity for "ill-informed" behavior by programmers. If you have a team of programmers who follow good coding practices anyway, runtime exceptions are less onerous.
 
reply
    Bookmark Topic Watch Topic
  • New Topic