0

(I moved this question here, as StackExchange fits better, originally I posted it on StackOverflow.)

This is not a question about a particular piece of code, rather I ask what is the right design approach in such situations.

More on the situation:

I am developing a sort of exception handling framework for a Spring Boot REST application. Although this is a bit grandiose naming for introducing the standard Spring @ControllerAdvice + @ExceptionHandler mechanism to the project, also a custom (parent) exception is introduced to mark the functional problems for the project.

I might be overthinking it, but is it OK to explicitly throw exceptions from the private methods of the business functional classes? Keep in mind that the business functional classes form something like an API for the Business Domain, as in DDD. This is the approach with less code, also most clear from a developer point of view, because I throw the exception exactly where the problems comes up. But if I wait (try-catch-finally) for the problem in public method, I might gain the ability to document it with throws declaration, also the clients of that business functionality with benefit from the increased readability.

Also, is throwing exceptions, especially, deliberately from private methods a sort of security risk? As it would expose the methods call stack in the stacktrace in the log?

6
  • I think this is hard to answer. What is 'ok' for one person/organization is not okay for another. E.g. java wants people to use checked exceptions, at least for business cases. But there are also a lot of people (including me) who think that 100% checked is a nightmare and 100% unchecked is better than a mix of checked/unchecked, and so would always use unchecked exceptions. So, what do you mean by 'ok'? Who will use the code? What expectations will they have towards the API and the exceptions?
    – marstato
    Aug 25, 2020 at 8:24
  • 1
    Also: DO write stack traces to your logs. Debugging becomes so much harder without. Your logs should be very well protected from unauthorized access; stack traces are the least of your risks/problems when your logs are available to the public / unauthorized people.
    – marstato
    Aug 25, 2020 at 8:26
  • 4
    If you could not throw exceptions from private method for whatever reason, you would effectively loose the ability to refactor too-long methods into several smaller ones. That makes no sense to me.
    – Doc Brown
    Aug 25, 2020 at 9:24
  • @marstato totally disagree, if everyone could decide on their own what is right & bad practice, then why are we trying to put in efforts towards improving our skills at all? we could just throw random, first ideas into the cake and.. job done!
    – gai-jin
    Aug 25, 2020 at 10:08
  • 1
    It depends on the convention your team is following so people won't get lost in inconsistent code. Usually when you need to throw exception, it means that there's no point in further execution. It may be validation issue for example. I've seen couple approaches to this kind of scenario: returning bool on success, having context object in business strategy objects and throwing exceptions. They all may have some application in different situations. Personally I favour throwing for how explicit it is.
    – yoger
    Aug 25, 2020 at 11:55

3 Answers 3

7

What a public method documents as the exceptions that can be propagated out of it (throws declaration) and where the exception actually gets generated are two completely different and independent things.

As soon as a method or function detects that it cannot fulfil its contract, that is the point where an exception should be thrown. This is completely independent of the visibility (private, public, etc.) of the method or function.

The throws declaration on a public method should document all the exceptions that a caller of that method might have to deal with (or at least be aware of). That is not just the exceptions thrown by the method itself, but also the exceptions thrown by functions/methods that it calls and which are not handled.

1

Ask not why you want to throw an Exception but why would you want to catch one!

The most important part of Structured Exception Handling is that last bit - handling the Exception. In my book, that means catching it and doing something "useful" with it.

What's "useful"? Well (as ever) it depends.

If your own code can catch an Exception, "deal" with it and make it "go away", so that your caller knows nothing whatever about it - that's useful!

  • In this case, having as much detail as possible (i.e. a custom Exception) would be a Good Thing.

If your own code can catch an Exception, log the details away somewhere and then construct a new, sanitised, Exception that is suitable for public consumption (as you should do at your component Boundaries) - that's useful.

  • Again, details are useful for you to diagnose the issue but other people don't need to know them (or, indeed, see the internal structure of your code).

If your caller's code can catch the Exception, reliably determine a course of action to rectify the problem ("try again" being a perfectly valid one), then that's useful.

  • Here a custom Exception is essential because no-one should ever try to interpret an Exception's message property. Always use it's class and/or custom properties.

If your caller's code can catch the Exception, log it and display a generic, "Oops, something went wrong" message to the User, well, that's useful too. Just not very useful.

  • A custom Exception is probably overkill here.

If your caller's code can catch the Exception, bamboozle the User by dumping the whole thing on the screen before the Application crashes and burns - well, that's just rubbish.

Sadly, though, this seems to be the sum extent of "Structured Exception Handling" to some Developers.

1
  • thanks, but this is a bit outside of the focus of the question
    – gai-jin
    Aug 26, 2020 at 14:09
0

Either the caller, in the same class, catches the exception, then there is no problem. Or the exception is passed to the outside, then it will become a normal part of the public method’s contract.

If I call your public method and receive an undocumented exception, that is obviously rubbish.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.