Yep, I totally agree that things are much easier when you learn how Merb rendering and Rack machinery works. Learning the internals of the tools being used is invaluable, especially when everything is really nice and neat under the hood like in Merb. Was pretty amazing that Yehuda was able to walk everyone through it from end to end in a little over an hour.
However... I don't think this fact excludes the usefulness of providing helpful error messages in the framework internals for common errors cases (nil body is a very, very common one). Much nicer to see immediately what went wrong in the Exception message (and immediately say, "oops I forgot to return a string!"), than an obscure "undefined method each for NilClass", which a very common error and not easily recognizable as to what the issue is without investigation and wasting some time tracking down the cause. On Jan 22, 8:45 pm, Michael Klishin <[email protected]> wrote: > On 23.01.2009, at 7:24, Jacques Crocker wrote: > > > Created a lighthouse ticket for the minor issue of adding a helpful > > error message to nil response bodies. Seems like pretty easy patch > > (one liner throw on the dispatch process), so I should be able to get > > it spec'ed and patched without too much problem > > Wouldn't it be easier to just learn how Merb rendering & Rack > machinery works instead? If you want to get something other than a > blog done, > you will have to do it anyway, and there is clearly a file and line in > the stack trace (compare this to cases when magical tool called Rake > dies and outputs *nothing*) > > MK --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
