How can we improve the error reporting?
When my service throws an exception (user session is expired), or just another kind of exception, some sort of bad request, how can we get better information logged?
Currently, I am hooking the logger into the apphost and it outputs something like below. Really would like to know everything about the request too! Like the things in requestlogger plug in (who, what, url, parameters, body, etc).
2014-02-19 15:44:31,344 [35] ERROR ServiceStack.DtoUtils [(null)] - ServiceBase<TRequest>::Service Exception
System.UnauthorizedAccessException: No User
at <stacktrace>
at lambda_method(Closure , Object , Object )
at ServiceStack.Host.ServiceRunner`1.Execute(IRequest request, Object instance, TRequest requestDto)
You register error handlers on the AppHost to get notified when there’s an error:
https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/IAppHost.cs#L83-L88
They both pass the IRequest in.
Wayne Brantley:
How does that play with the way it works now? Would I be completely overriding what you have in place to do this reporting now? We discussed previously some additional plug in points around me being able to easily intercept and handle particular exceptions and still call base handler if I did not want to handle. Is that possible? Also, I would think with the default logging you are providing now it would make sense to output this basic info wouldn’t it?
They’re handlers where you can listen for events, you can change what error gets returned in by returning a Error Response DTO, if you want to retain the same behavior return null.
Wayne Brantley:
Ok, I will look into that…I think you should consider better ‘default’ logging too. Thanks.
Add a feature request if you want anything changed, with details like the extra info you want logged.
Wayne Brantley:
Boo. I just do not see anything happening over at uservoice. Very little activity, very few votes and nothing of the ‘planning’ or what you are doing next? However, I will comply and add it.
Wayne Brantley:
BTW, I of course already added it 4 monts ago, I will add some details. http://servicestack.uservoice.com/forums/176786-feature-requests/suggestions/4688456-better-request-and-exception-logging
The feature requests is to catalog work items, and to measure interest and have a discussion around what’s needed and how it should be implemented. I’m not just going to implement every micro feature request that’s shouted at me, there needs to be a very good reason for it it to interrupt what I’m doing and start working on it. The feature requests are being prioritized by interest and whether it’s a good fit, and the highest priority feature requests are being implemented, and more will be as I get more free time to work on it.
As for this logging I’ve already explained the custom hooks you have available in order to do what you want. But you’re asking that by default I should change the current behavior and make everyone’s logging more verbose, even when no one else has expressed interest in it. The feature request is there to measure interest and to find out exactly what everyone wants logged.
Wayne Brantley:
Demis, I understand everything 100%. I am not asking you to implement every micro feature. You may be implementing the higest requested feature - but uservoice does not indicate you are ‘planning’ on doing any of them. Any chance you would use uservoice and mark ones as planned or implemnting or whatever so we all see what is coming next?
I change the status when I implement them and mark them complete when they’re done. Like most software companies, I’m not planning on committing to any timelines. They’ll get done as soon as I’m able to ship them.
But the next few major ticket items I’m looking at is:
- Built-in AD Support
- Management UI
- Then see what I can do to improve OrmLite’s data access patterns.
A lot of these also require a fair amount of R&D.
But the immediate work is to change the website to support the new products now that the Into discounts are ending, then to create new individual products for the individual products that many people have been waiting for. In the meantime, I’m also upgrading all the SS. Examples and UseCase projects to v4 and adding a new Example project I’ve been working on that show’s an example of “good architecture” for medium sized projects. Also working on other stuff that I prefer to “announce” only after its available.
Keep in mind there’s a lot more overhead to running a product/support company then just development. Unfortunately development is only being done in the time I have left over. As a result I’m very conscious about my limited time and try to maximize it wherever possible.
Wayne Brantley:
I am was only suggesting you put these 3 items you are ‘looking at’ in the ‘in planning’ stage on uservoice. Hey, I know all about all the things required to run a company…just remember you used to work on SS on your ‘time left over’ too…and so now we don’t want to be in the same boat as before! Of course, right now there is a lot more ‘startup’ stuff involved. Thank you for your time.