This question probably totally exposes my inexperience, but oh well!
Previously when I was working with Data Object services and my code threw an error, I was able to look in the agent log to figure out what had gone wrong. I'm re-implementing one of those services in the new object-oriented WebSpeed, and that seems to be swallowing up the errors by default instead of logging anything out. There's nothing useful in the JSON response from the server, either.
So in short, what's the easiest way to figure out what is causing my WebSpeed service to return a 500 response?
Can you increase the logging level to 4 and try again? The default WebHandler class will log messages at level 4.
Hello,
Just a quick reply.
Perhaps, the request is not getting to your code. Was the new code published?
Have you tried adding messages to the WebHandler or increasing the logging level?
The localhost and localhost access log files may also have messages.
If you comment out the code, does the error 500 go away?
I hope this helps.
The request is definitely getting to my code - if I find the faulty piece of code and wrap it in a structured error handling block, I can message out the error manually. That's how I've been dealing with it so far, but it's a bit of a pain!
Increasing the log level from 2 to 3 didn't do anything that I could notice, and the localhost and localhost access log files don't contain anything useful.
The localhost and localhost access log files would be for when there are errors outside the code.
I think that the key here is what you mentioned:
> - if I find the faulty piece of code and wrap it in a structured error handling block, I can message out the error manually.
Perhaps, the WebHandler needs the following statement:
BLOCK-LEVEL ON ERROR UNDO, THROW.
The Business Entities in the Data Object Services include this statement.
I did think that might be the case, but all of my handlers already contain the BLOCK-LEVEL ON ERROR UNDO, THROW statement! I believe it gets added by default when you create a WebHandler in Eclipse.
Can you increase the logging level to 4 and try again? The default WebHandler class will log messages at level 4.
I didn't even realize there was a level 4! I'll give it a go.
If you want to get in details of what is wrong with the code then you add the below logging
agentLogEntryTypes=ASPlumbing,DB.Connects,4GLTrace
agentLoggingLevel=4
You and Fernando are correct, that worked! Only downside is the ridiculous amount of other info that shows up in the log with it set to level 4...
Now, a possibility for debugging would be to customize the WebHandler class and add your own message to the HandleException method, which is called from HandleRequest(), where the CATCH block is.
Ideally the catch block should give you the error, but if we do not understand where it is coming from then we have to go for the 4GLTrace