3

I want to know whether it would be right to use exception classes as regular classes to handle application errors (just regular controlled errors, not exceptional ones), without throwing them with the proper language clause (eg. instantiating them and returning them from a method). I've been discussing this topic recently with some colleges and I think that exceptions should only be used as exceptions, but I'd like to listen to more opinions.

Nikolay Fominyh
  • 8,946
  • 8
  • 66
  • 102
beni0888
  • 1,050
  • 1
  • 12
  • 40
  • 1
    `eg. instantiating them and returning them from a method` <- As an expected return type like `public RuntimeException doSomething()`? What would be the point of that function if it allways returns an Exception, or would you return null if no error happened? Really having trouble understanding what exactly you mean. – OH GOD SPIDERS Feb 20 '17 at 17:29
  • yeah, the point is as you've said, returning the exception or null, or even returning an `Optional` or a similar construction in other languages. – beni0888 Feb 20 '17 at 17:38
  • Why would you do that? You'd be using a language construct in a way it isn't meant to be used, without getting any advantages. The only place where you might return an exception from a method is in an exception builder situation, but even then you would eventually throw the exception. – Kayaman Feb 20 '17 at 17:41
  • @beni0888 Returning an `Exception` instance would be as good as returning an instance of any other class. What advantage do you see with this approach? – Chetan Kinger Feb 20 '17 at 17:57
  • 1
    @beni0888 I published a post on [designpattern.ninja](http://designpattern.ninja) about this topic, or at least, it seems that you might be interested on double checking it: http://designpattern.ninja/news/2017/02/05/exceptions-vs-errors-the-final-showdown – Matías Fidemraizer Feb 20 '17 at 18:04

2 Answers2

1

What you mean by "controlled error" is actually known by the name checked exception.

"Exceptional exceptions" are known as unchecked exceptions.

The difference is explained here: Checked vs Unchecked exception

So, you see: Java comes with a built-in mechanism to distinguish between

  • exceptions caused by programming mistakes (e.g. NullPointerException when passing unexpected null as an argument) -- unchecked exceptions
  • versus anticipated exceptions that should be handled by the caller (e.g. IOException when some kind of I/O went wrong) -- checked exceptions

Returning instances of Exception (or any subclass) would be considered a misuse in virtually all circumstances.

You could ask your colleague how he/she would implement an exceptional outcome of a method with this signature:

public String createStringOrFailWithException();

Returning an Exception? Certainly not, because this requires a different return type.

Throwing the exception instead allows you to keep the return type, and to benefit from vast exception handling capabilities, including finally blocks and try-with-resources statements, to give only two examples that you don't want (should not) implement by yourself.

Community
  • 1
  • 1
Philipp Merkle
  • 2,555
  • 2
  • 11
  • 22
0

I suggest keeping Exceptions "exceptional". I.e. don't build them into your app logic. Use more meaningful things like a ActionXResponse class etc that could indicate failure, and even have an Exception as a property which the controller could check for "controlled exceptions". It's much more meaningful when you have your own class as a response.

Another guideline I'd suggest, along with keeping Exceptions "exceptional" is to avoid checked Exceptions (compile-time).

Don Cheadle
  • 5,224
  • 5
  • 39
  • 54