1

I am just looking for a little best-practice advice.

I have a service, "price sheet service" where by a user can save a price sheet of some sort.

There are a few instances or configurations that can leave inconsistent data, and in those events I want to end the function execution.

An example would be if the customerId wasn't set on the object, or the salesperson's userId couldn't be found in the database.

My question is what is the best way to leave a function when you encounter a business logic error?

I like the way Exceptions stop execution right there and allow you to re-throw the Exception. The problem with that is, I've have heard exceptions aren't to be used for flow control.

Currently I just have a bunch of nested if/elses whereby I don't commit my transaction unless the local variable of $service_error_message hasn't been set.

If $service_error_message is null then I know none of my validators have failed and it is okay to save.

Does anyone have a suggestion for how to better handle these scenarios?

Jonas
  • 97,987
  • 90
  • 271
  • 355
Black Dynamite
  • 3,723
  • 5
  • 34
  • 63
  • 1
    If the problem that can occur is part of the normal execution of your program, I would not use exceptions nor things like `die`, you simply need to test for valid input and present an error message to the user. – jeroen Aug 13 '12 at 15:50
  • @Leigh Thanks for the readability enhancement Leigh. – Black Dynamite Aug 13 '12 at 16:08

2 Answers2

2

If you encounter an error that is unquestionably fatal, no way of recovering from it, clean up and exit. If you have no clean up to do outside the scope of the current procedure (closing files/DB connections/whatever, generating some error output etc) then simply exit makes the most sense. If the error is potentially recoverable, or you want to clean up/log the error in an orderly fashion by some means external to the current procedure then an exception makes the most sense. It's a case-by-case decision.

I've have heard exceptions aren't to be used for flow control - this is true but doesn't really apply to the situation you are describing. If you encounter an actual error then an exception is perfectly acceptable. What you shouldn't do is use exceptions to determine which piece of code is executed next, sort of a re-hash of goto.

A good explanation of what not to do and why not can be found here.

Community
  • 1
  • 1
DaveRandom
  • 84,004
  • 11
  • 142
  • 168
1

Typically I would not use Exception for flow control,as if I am expecting some conditions to regularly occur to where I want to bail out of the script I would use an exit() call.

In my opinion, Exceptions are to be thrown only when you run into something in your code that should not take place (like invalid parameter passed to an object's method or a function) - i.e. something that is truly exceptional. I would also only use them in cases where I have try-catch blocks around the calling code that can catch and handle the exceptions appropriately.

So for example, I might have a case where I instantiate a database connection within a try-catch block and then have the DB abstraction layer throw an Exception in cases where the connection could not be established.. I would then catch the Exception and log it and exit() out of the application appropriately if the database connection is absolutely essential to the functionality of the service.

To me, just getting empty result sets from a DB query (i.e. checking a user login) is not something that I would not handle by throwing an Exception, but would rather provide an appropriate end user message and exit from the script gracefully if need be.

Mike Brant
  • 66,858
  • 9
  • 86
  • 97