1

I am doing a Java Spring-Boot backend project and I am implementing a controller-facade-service pattern on my structure.

So is it best to put all my error handling on the facade layer, while the service just throws the errors occured, and the controller just receives the response entity produced by the facade?

I imagine it this way becausae the facade will be the one place for wrapping up ResponseEntity, if it is an error or a success call, leaving also the controller a cleaner code, just for calls and received responses.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
alona
  • 21
  • 3

2 Answers2

2

No, it is not okay. A facade may simplify the interface or be used to only make public specific methods, but conceptually, think of a facade as a lens. It's supposed to act as a bridge between parts of your program, but you wouldn't probably ever want to handle errors in one, because the errors being returned are very much relevant.

That said, you're encouraged to catch and rethrow or catch similar exceptions and rethrow as another. Though you wouldn't want to, say, catch all errors, then return null because null may be a legitimate response by your class.

Granted, maybe you know the method would never return null and therefore returning nulll in your facade could be treated as an error, but a facade shouldn't make such considerations when it's very dependent upon actual implementation of said method getting called. Should that change in the future, it'll be one tough bug to find.

Neil
  • 22,670
  • 45
  • 76
  • I think OP ment to catch all errors and wrap them in a final response object which then be displayed or sensed back to consumer. So facade layer will never returns null. – Fabio Jul 03 '18 at 18:11
  • 2
    OP's facade layer **is a bridge** between business logic and consumers which wrap results/errors in "friendly" objects – Fabio Jul 03 '18 at 18:13
1

The purpose of the facade is as a go-between. It doesn’t actually DO anything itself. Any methods it has only serve its purpose as a bridge between two things (controller and service in this example.) So, as a dumb example, maybe the service takes two arguments in the form of first and last name, but the facade will take a single argument from the controller in the form of a full name. The only work the facade does is break the single argument into the pieces that the service expects.

But Error Handling requires more sophisticated logic, and putting it in the facade would have the facade doing something. The facade may hear the error or errors from the service, but the only thing it will do about the errors is package them up and pass them along to the controller. Sticking to my example above where the facade takes one argument and passes two arguments to the service. Let’s say the service is supposed to return two values and the facade is supposed to return a single value to the controller. If there is something wrong with one or both of the values coming from the service, the facade may be designed to throw just one error to the controller where it will be handled. (Or possibly thrown again to some other part of the code.)

I’m not familiar with Java or the spring framework, but it looks like the whole point of the ResponseEntity is to combine the httpEntity and httpStatus. I don’t think it’s the facade’s job to break them apart and do things with them. The facade should pass the ResponseEntity to an object that expects to receive both the httpEntity and httpStatus.

esoterik
  • 3,879
  • 3
  • 13
  • 22
Chuck Floading
  • 11
  • 1