Went WTF on exception handle...(java)



  • All the guidelines i know encurage me to set the cause for my exceptions. This worked well until in a client server application i had an org.postgresql.util.PSQLException on a server and it had to get as cause for one of my exeptions to the client. What did those guys from who wrote that PSQLException...they extended SQLException and added a field of type org.postgresql.util.ServerErrorMessage. Boom... class not found on the client.

    Can you point me to a document or something telling how to deal with such things if i'm wrong? For all that I know all I did was best practice and never had a problem. Of course i can walk around this with a fix but I still think "WTF this shoudn't happend, THEY should have been more careful in this situation, not me".



  • I think you posted this in the wrong forum - are you asking for Java programming help?



  • Well, if I'm understanding you correctly, your problem stems from using some sort of serialization technique to transmit the actual Exception from the server back to the client.  Naturally, in such a case, if you don't have the postgresql jdbc jar on the client, you'll muck things up.  While including a cause is good practice, it's not mandatory.  I see nothing wrong with simply including the exception details in a new SQLException which is sent to the client, but without a cause.



  • I'm not asking for help. I used lot of 3th party project and never had a problem like this. When I send an exception over the network only for logging purpose I shoudn't be bothered by a class not found exception. Of course I don't want to include postgres jar, or even parts of it, on the client. My point is: shoud I check each project that I use to see if I can or can't include their exceptions as a cause for another one?



  • What? This is a tech help forum now?

     

    I think we just had a meta-wtf! 



  • There's actually a seperate forum for help: http://forums.worsethanfailure.com/forums/19/ShowForum.aspx



  • I'm not sure which way is more "correct," but I've seen many JDBC drivers throw their own subclasses of SQLException. You do, however, give a good example of why they probably should avoid doing so. (I wonder if this is the reason for the addition of so many specific subclasses of SQLException in Java 1.6.)



  • The WTF at hand is that you send detailed server exceptions to the client. You could be relaying more information to the (presumably untrusted) client than you want to. My advice is to do the logging at serverside and send a simple string or nothing as the cause. I don't even see why you're sending a SQLException back. Does the client need to know that your server is using sql?



  • @VGR said:

    I'm not sure which way is more "correct," but I've seen many JDBC drivers throw their own subclasses of SQLException. You do, however, give a good example of why they probably should avoid doing so. (I wonder if this is the reason for the addition of so many specific subclasses of SQLException in Java 1.6.)

    So you can handle them appropriately in a uniform, type safe way? 



  • @Luke said:

    I'm not asking for help.

    @unklegwar said:

    What? This is a tech help forum now?

    "What?" indeed.


Log in to reply