#midgard

I'm again struggling with a problem where we are trying to build up a new site's production server and Midgard gives Error 500 Object not found. Of course this kind of is our problem because we obviously have some object missing for some reason.

However, in this situation it would be very practical if Midgard could even tell me what type of object is missing. In current situation I have no idea where to start looking... and there are like 100 files in the system... and it is very very annoying.

@piotras Could Midgard tell me what kind of class is missing? I know Midgard knows it anyway.

Ok, in this case it was just a non-updated schema but the improvement proposal still remains.

I think it's much easier to catch it on application level. If it's constructor, you should catch exception. In any other case, checking midgard_connection::get_instance()->get_error is not so difficult.

@piotras Ah, but I don't mean you should catch it in midgard. I just hope that instead of "Object not found" you could echo e.g. "Object {$classname} {$uid} not found". It would save several minutes from the developer every time this happens. And after all, isn't saving minutes from the developer one of the most important things a platform should do ;-)

@TomiS Still, I do not understand what does prevent you to handle errors on application level.

@piotras Nothing prevents me to do that, I'll give you that. But it's a bit impractical and, in my opinion, a wrong way to use try-catch. As far as I understand, try-catches should be used when application needs to live through certain unlikely but possible situations without crashing. In my example case (and many similar and less similar cases) I don't want the application to survive. It should crash because it doesn't have something right (e.g. proper schemas installed). These are situations that the user of the site will never see but as an app developer I would like to solve them as quickly as possible. You can't find a developer who wants to spend four extra rows (minimal try-catch) just to throw a better try-catch (or die) just to make application die more beautifully in a situation where it should die anyway. Especially when it could be done on a platform level much easier.

@TomiS I think I do not understand use case here. We are not talking about object constructor. And if not, what is the use case we talk about? Another thing is that, these four extra rows become 44 extra rows in core making code less readable. And try/catch is to catch exception on application level, which, itself is responsible to make decision if to die or not. Any abort triggered from core would be very very bad thing here, cause it doesn't let you (at any minimum level) to catch error. In your case, it would end with apache process being badly killed (with or without error massage).