Exception handling, boolean, writing my own... headache

Greetings!

I am working on a java imap module which can be used to make connections to an imap server, manipulate folders, read mail, ...etc. This is intended to to be used by several other software projects in the future.

Since I started with Java, I've always struggled with exceptions. Not so much how they work, but more in regards to the best way to use them. Presently I'm seeking advice on the following within an ImapConnection class I'm writing:

connect() simply throws IOException upwards (because different users of this module may want to handle it differently)

What to do on a failed login() is where I'm stuck. At present (as above) I'm returning boolean, but this doesn't feel right or in keeping with the rest of the class. I've considered writing my own checked exception specifically for this and throwing that, but that goes against the general advice of trying to make use of existing exceptions. I've also considered throwing something like FailedLoginException, but that would require me to include javax, which I'm otherwise not using for anything.

So I suppose I'm just looking for general advice for this situation or situations like it. Is this the correct use case for writing my own exception?

As an addendum to this question, I've also spent considerable time "meditating" on the question of whether or not I'm breaking the "don't use exceptions for flow-control" principal. In the end I've determined that in this case deciding to "catch and handle" or rethrow should be left to the next layer up for maximum flexibility. However, I'd welcome any thoughts on this as well.

Thanks,

C

Hi Clayton,

Sounds like you've given this some good thought! For what it's worth I think the design of your login() method is fine _assuming_ e.send() and e.expect() don't throw Exceptions.

Typically when I design login flow for one of my JCA connectors, I often have a method as a public API call that clients can utilise.

Inside that login() method I catch Exceptions from the underlying resource and log them appropriately. It's the getting back an appropriate message to the client that can be tricky in this case as a boolean return value doesn't tell you why something failed. We typically put those messages on a separate message bus.

That said I've also occasionally written methods that can throw the LoginException with the message if something goes wrong. This gives you a direct path for the message back to the client.

I don't think there is a right answer, but others might disagree

Have you read the excellent "Effective Java" book? It has some nice recommendations about Exception Handling

Martijn,

Thank you very much for your response! Part of me thinks that I should either go with boolean for both connect() and login() or go with exceptions for both (do the same thing for both). Maybe I can catch the IOException for connect() also and return boolean there as well (and use logging for both as you suggested).

The e.send() and e.expect() methods are both boolean based and catch/log lower level exceptions, so I guess I've already started down that path.

Can anyone comment on my thought of using an exception from a different class (FailedLoginException for example)? I've actually decided against this in this case, but I'm curious if this sort of thing is generally considered acceptable? In the case of FailedLoginException (from javax) - it's clearly not intended for my specific situation, but the *name* of the exception fits perfectly. Do people find it an acceptable practice to use a particular exception based almost entirely on it's name?

Have you read the excellent "Effective Java" book? It has some nice recommendations about Exception Handling

It's funny you should mention this. I'm about a quarter of the way through this book right now. In fact my Imap package was halfway written when I started reading this book, and the book has been the source of much consternation! I love the book - but as I read, I keep going "Oh!, Oh! That's exactly what I should have done!" Then I feel compelled to go back and re-write/re-structure a bunch of stuff. It's really slowing down my Imap project (but for good reasons, so I'm ok with it) :-)

Thanks,

C

Hi Clayton,

Glad to hear the book is leading you down good paths, I personally don't read it enough (I'd re-factor my code forever otherwise I think ;p). I forgot to comment on your 'making your own exception'.

Perfectly acceptable, as you say just be cautious in creating too many of them. We follow a 'rule' that they should only be used to wrap up lower level exceptions so we provide a simplistic exception model for clients to deal with in our API.

If you create your own Exceptions, it is probably a good idea to create one Exception as a superclass (directly or indirectly) for all the other types. Then you can catch them all together, should you need to.

Thank you both very much for your suggestions! I think I have enough to go on now. Hey - if it doesn't seem right when I'm done, I can rework it.

C

You're welcome!