5

Working through several layers of an MVC architecture designed program, I find that I would like to have more information on a deeper layer's method return result, and that it's not always that I can anticipate when I'll need this information. And - for abstraction sake - I might not want that method outputting stuff to the application-specific log (that method could be used in a different program), or have a specific application dependent behaviour like other layers above.

For instance, in a given utility function I might have several pre-requisite checks before executing an action, that fail. If I return false on any of them, the caller doesn't know what happened. If I return false and log to the application log what happened, I'm bounding that function to application specific behaviour.

Question is: is it good/common pratice to implement a little class called MyResult and have it return the response status (ok/false), a message, an eventual integer code, and an object placeholder (array or object) where the caller could access the returned object? This MyResult class would be used throughout the whole system and would be a common "dialect" between all methods and their callers. All methods would then return an instance of MyResult, all the times.

Pedro Mata-Mouros
  • 186
  • 2
  • 9
  • What, all of them? `getInitialsFromName()`? – Amadan Jun 12 '11 at 15:25
  • is there a reason why you can't use Exceptions? You can extend an exception and fill it with whatever information you need, but at least you create the object only when there's actually an exception, not always. The idea of functions creating a return object no-matter-what seems a bit overkill. – magma Jun 12 '11 at 15:27
  • @magma Well I've always looked at exceptions as just that: exceptions... And I kind of loathe putting everything in try catch blocks. In my book exceptions should be ok for handling a few extraordinary cases, and/or for easy "messaging" through components of different libraries on a less than frequent basis use. But I agree that having a MyResult object created for the specific purpose of being returned as a response could be overkill... – Pedro Mata-Mouros Jun 12 '11 at 20:57

3 Answers3

2

That's what exceptions are for. You don't have to over-do them like Java, but they exist because error codes suck.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • Well... I don't find it feasible to have Exceptions being used to "emulate" return codes and objects, as well as they demand try/catch blocks everywhere in the code... I could use Exceptions for really exceptional stuff, but I'd like to come up with something more universal to be used throughout my "framework", in terms of components querying and answering each other. – Pedro Mata-Mouros Jun 12 '11 at 21:07
2

Could you give an example? It seems a bit, but I can be mistaken, that you are having methods you are using statically (even if they are not implemented/called like that they could've been). The basic example of the table-object that can paint itself is called like so: $myTable->paint();. It can return a variable if it worked or not (true/false) but any other thing (like logging) is a function of table() and neither your calling method, nor the return value should have anything to do with that as far as I'm concerned.

Maybe I'm having a hard time understanding what situation you are going to use this for, but if you want to send messages around for some purpose that requires messages (or events etc) you should define those, but I don't see any merit in defining a default returnObject to pass around method-call results.

For errors you have two options: exceptions (that is: things you really don't expect to happen and should halt execution) and errors: expected but unwanted behaviour. The first should be left alone, the second can be tricky, but I'd say the object itself should contain a state which makes it clear what happened.

Nanne
  • 64,065
  • 16
  • 119
  • 163
  • your example is good enough. In that case the method might return a variable, might return true or false and there could even be situations where you would want to log that. If paint() would be a core method that you wanted abstracted from your application logic, it should have no business logging anything - but maybe in your specific application that would be desirable. In that case, we'd have the following options: 1. Exceptions (which should be exceptional, as well as they warrant try/catch blocks everywhere), 2. MyResult objects and 3. object keeping state for later inquiring. – Pedro Mata-Mouros Jun 12 '11 at 21:02
  • The proper answer to the original question would be that: 1. Exceptions are bad for anything other than just that (exceptions) and 2. MyResult type objects returned as results would probably be overkill in every single method call. Depending on the specific needs in question, it may make sense, e.g., to implement MyResult type objects in factory method calls or any others that could return object instances or arrays of object instances. Guess it's just common sense on the programmers side to not overdo it. – Pedro Mata-Mouros Jun 14 '11 at 13:46
1

If a framework does not offer a specific feature you need, there is no other way then that you take care on your own. Especially if you need something that runs cross the aims of the framework, so would never make it in.

However, many frameworks offer places in which you can extend them. Some are more flexible than others. So if possible I would look if you can still implement your needed feature as a type of add-on, plugin or helper code that can stay within the frameworks terrain.

If that is not possible, I would say it's always valid to do whatever you want to do. Use the part of the framework that is useful for you.

hakre
  • 193,403
  • 52
  • 435
  • 836