-1

I am working on re-writing a business layer for one of the apps in company. For now, the business layer will interface directly with the web client. But in the future, it will be encapsulated with service interfaces and will be consumed by the same web client.

My question is that when a validation exception or other exceptions occur in the business layer, is it okay to throw custom exceptions or would it be better to use custom objects that represent errors ... like ValidationError, etc? Is it more expensive to throw an exception vs returning an object?

dotnetom
  • 24,551
  • 9
  • 51
  • 54
Skadoosh
  • 2,575
  • 8
  • 40
  • 53
  • Surely you'd want to respond with an HTTP Response code most closely related to the failure. The exception is exceptional, right? HTTP is how communication happens on the web. – Jodrell Oct 14 '14 at 16:28
  • I tend to stick the validation in the domain rather than any particular service layer, i.e. validation is part of the object model. Then you can validate at whatever layer you wish. – Ben Robinson Oct 14 '14 at 16:29
  • @Jodrell Absolutely! Once the services are implemented, the appropriate error code will be returned along with some kind of object/exception that tells more about what happened. – Skadoosh Oct 14 '14 at 16:30
  • @BenRobinson I will have the domain objects behind the service layer (separate from the service layer). How do you generally alert the client of any validation issues? – Skadoosh Oct 14 '14 at 16:34
  • Why is this voted down?? This is a legit question ... – Skadoosh Oct 14 '14 at 16:35
  • That depends on what you use to build your services. I tend to use web api which has a built in method to return a bad request response with the validation errors as the body. – Ben Robinson Oct 14 '14 at 17:20

2 Answers2

0

The most popular thought on this today is to throw the errors towards the application layer. I guess the idea is so that the interpretation of what went wrong and telling the user is more clear there than way down in the guts of the applications.

Some people catch errors everywhere and then throw them as they go, this leaves a trail of traceable documentation for the developer.

One other interesting point, if the developer makes all the error messages contain unique identifiers, then they are easily able to debug because they can pinpoint the code just by looking for that number.

JWP
  • 6,672
  • 3
  • 50
  • 74
  • I wouldn't want to use codes in my error messages. I once read an article that advised to stay away from magic strings. I guess that just stuck with me. – Skadoosh Oct 14 '14 at 16:32
  • Let me clarify, I use combination of codes and message for example: "GCS300-Get Customer Failed" where GCS is the module name, the 3 is the severity and the last 2 ensure uniqueness. When someone calls me I can immediately look at code and get a clue... – JWP Oct 14 '14 at 16:41
  • Aah. gotcha. That makes sense. So, then would that code & message be part of the exception message? – Skadoosh Oct 14 '14 at 16:53
  • Yes you want to expose the title of the message to the user, that way when they call the help desk, the help desk can look for all messages of that type and knock out 80% of the noise, by the time it comes to me, it's definitely something needing to be fixed. In other words the Help desk already knows this is NOT a user induced error. I always use the third character for severity with 1 being highest and 5 lowest. Anything 3 and less is just user information anyway.. – JWP Oct 14 '14 at 17:24
0

Throwing an exception is way more expensive than returning an object. Exceptions should be used only for unexpected situations. Errors in validation of user input is not unexpected and should not result in an exception being thrown.

Mike Stockdale
  • 5,256
  • 3
  • 29
  • 33