1

I have views that handle different errors in my application. For example error 404, 403 and such, giving my errors a more user-friendly presentation. By assumption, they get passed in an exception, so this is what an example error-handling view looks like:

<h1>Whooops! An error with code <?=$exception->getCode()?> has occurred.</h1>
<p><?=$exception->getMessage()?></p>

But somewhere along the lines I met a need to display a certain error view as only a part of a page, so I decided why not do this

// somewhere in another view
echo $errorView->render(new \Exception('Message', 403));

My question is whether in my particular case it is a good programming practice to be throwing exceptions? Or should I handle it differently than how I am handling it now?

AvetisCodes
  • 1,544
  • 3
  • 14
  • 26
php_nub_qq
  • 2,204
  • 4
  • 17
  • 25
  • Since an exception can be thrown any time you feel like it, the obvious answer to "[are exceptions thrown] only if something really critical has happened?" is "No." Exceptions can be abused just like anything else. – Robert Harvey Mar 25 '15 at 18:43
  • @RobertHarvey is what I've done considered bad practice, because in java it would be, if possible at all. – php_nub_qq Mar 25 '15 at 18:46
  • 1
    Throwing an exception without an exceptional condition is a bad practice in any programming language. Java doesn't prevent you from doing it. – Robert Harvey Mar 25 '15 at 18:46
  • @RobertHarvey So you would advise against my current approach? – php_nub_qq Mar 25 '15 at 18:47
  • I just don't see what the point of the exception is, especially if you can render the error in the usual way. – Robert Harvey Mar 25 '15 at 18:53
  • 1
    @php_nub_qq: Can you explain your usecase where you need to render an exception that wasn't thrown? – Bart van Ingen Schenau Mar 25 '15 at 18:56
  • @gnat: Note that in this Q nowhere the exception is used to affect the control flow. It is rather the reverse: showing information from an Exception object that wasn't thrown at all. – Bart van Ingen Schenau Mar 25 '15 at 18:59
  • @RobertHarvey Exceptions are idiomatic in Python; for instance that's how `for` loops know to stop iterating (unlike e.g. Java's iterators that query `hasNext`). There's no such stigma in Standard ML either, but they don't include stack traces in that language (unless you ask the compiler in some compiler-specific way) so the cost of throwing them is much lower. – Doval Mar 25 '15 at 19:16
  • @BartvanIngenSchenau that is the point of the whole question. The view I'm rendering was meant to work with exceptions passed as a parameter to it, and I need to use this view within another view. – php_nub_qq Mar 25 '15 at 20:56

1 Answers1

4

You've got a situation where an exception occurs for some reason or another. There's really no point going on and you need to start bailing out and rendering the corresponding web error page (this is a web application after all).

Now, to present some information to the end user, you need to somehow get some data to that error page. And to that extent, an exception is a good place to put that data.

Other options are convoluted where one tries to stuff the data in a session context or somewhere that is 'anywhere but the exception'. But why not the exception? It can hold data (be it a message or the type of the exception or any other data that it is wrapping in other situations) and it is present when you are rendering the final response.

Using the exception to hold this data is the perfect place to put such information. It keeps it together, it makes it available to the parts of the application that need it and it clearly shows its intent and responsibility.

Should error pages only take exceptions? That is a bit of a trickier question. And that, it feels a bit awkward in that you are creating an exception object, but not throwing it and instead passing it as an argument. And that has some 'icky' feeling to it, but could be necessary for other parts of the application that aren't presented here.

Other parts of the application may behave specially when exceptions start floating around (like loggers or other cross cutting aspects taking action when an exception is created). But, again, without further information about the architecture this is pure speculation.

I would be tempted to make an interface of an Error (note that this is kind of hand wavy here and may not be applicable to all language paradigms). Then have a specific exception type implement this interface... along with a non-exception object implementing it too. Then have the Error object be sent to the rendering page. This would allow one to create an ErrorException when needed, but also just creating an Error when you don't need an exception.

  • Thankfully, someone understood my question. This answer brings me much comfort! Thank you. – php_nub_qq Mar 25 '15 at 21:03
  • @php_nub_qq I've been working with Spring recently and [working with exceptions that become error pages](https://spring.io/blog/2013/11/01/exception-handling-in-spring-mvc) which, well, is *exactly* how you get the error information to the appropriate page. So it doesn't seem odd to use it to pass around data too... but its still an exception that gets thrown. –  Mar 25 '15 at 21:07