report text of malformed querries in Logcat

[matkoniecz]

removes need to create temporary debugging statements during development
currently with code causing 400 errors one must create temporary debug entry outputting failing query, now this will be done automatically

part of fixing 24ac256 that is part of fixing #920 that is part of fixing #685 :)

[westnordost]

OverpassMapDataDao is supposed to be not coupled with Android code. Using the Android log system would do that.
Also, I do not understand what you are trying to achieve here and how this solution would help (you), actually.

[matkoniecz]

Also, I do not understand what you are trying to achieve here and how this solution would help (you), actually.

It helps if one has a bug in code that creates malformed overpass queries.

Such bugs causes Overpass to return 400 error code and 400 error code always indicates a bug.

Currently I always create a temporary debug entry that is outputting generated query - with this code it would be no longer necessary and query would be automatically printed to a log.

Using the Android log system would do that.

I was no aware about that, I will look for a better place to place this (if that is possible). Though I am curious why

OverpassMapDataDao is supposed to be not coupled with Android code

after all, this program will always run on Android - and logging should not have side effects (except logging).

[westnordost]

I was thinking of putting that class into osmapi, actually. But in general, I want of course as least coupling as possible.

So if you want to debug possibly wrong Overpass QL strings, why is the current behavior - that it crashes the app and thus prints the stack trace - not sufficient?

[matkoniecz]

It is only giving me info that query is malformed and not showing query itself.

Showing query that was generated (and was malformed) is very often useful to pinpoint the bug and see what went wrong.

[matkoniecz]

I was thinking of putting that class into osmapi, actually.

I will look at it.

[westnordost]

If the api error response contains a syntax error description, you can put that information into the exception. If not, you can put into the exception what you are currently outputting to the log.

…

On 9 March 2018 09:02:42 CET, Mateusz Konieczny ***@***.***> wrote: It is only giving me info that query is malformed and not showing query itself. Showing query that was generated (and was malformed) is very often useful to pinpoint the bug and see what went wrong. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #954 (comment)

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[matkoniecz]

I will submit an updated version once I again create code that requires debugging due to 400 error code.

[matkoniecz]

@westnordost

new variant of that: what you think about matkoniecz@76fc967 ? Would it be also be rejected due to unclean architecture? (String in StringWithCursor becomes public)

This just allowed me to track down irritating and silly bug in the query syntax

[westnordost]

Yes, likely to be rejected. An exception does not usually include the object itself (in this case a string).

What bug did you track down?

[matkoniecz]

query starting from """"nodes, ways

(multiline string that got fourth " character)

[westnordost]

Shouldn't it fail with a message like "yadda yadda yadda at cursor position 0" or something similar?

[matkoniecz]

oh it failed: but I was unable to spot it (syntax highlighting could be smarter instead of making it entirely green). I have simply looked at """" and seen """

And error message about parsing failure at position 0 of "nodes, ways was much more obvious to interpret