Is it wrong to add fields to exceptions? I have a problem that happens and I'm thinking of adding considerable information to an exception, but it sounds weird: an exception with getters.
What you think about this?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
What's wrong with it? Exceptions are still objects, they are just passed in a different way when being thrown.
Properties can make exceptions be more informative than just an exception message that (supposedly) is human-readable. If you catch the exception, you can receive information regarding the issue, and probably fix it automatically.
I like to quote Bill Venners saying, "Throw exceptions at programmers, not at code." I think it's a good rule of thumb.
Why not concatenate all information into the description string of the exception? The cost of String concatenation won't be incurred unless the exception is thrown. You aren't going to do anything with that info besides print it out anyway. Are you?
Unless, you actually want your program to react to the exception in some way. In which case, I'd again turn to Bill Venners "Or" class. He presented it in his Functional Error Handling talk. It holds an object (just like Optional or Maybe) which can either be a
Good<T> value or a
Bad<U> value. A Java Or is available as well.
Just because you can do more with exceptions doesn't mean that you should. Functional programmers eschew them altogether because they are a side effect, and an escape hatch from your code that is hard to reason about.