This could apply to Reporting, Perspective and, probably, Vision.
Default parameters can be useful in testing but can be problematic in production. A malformed URL parameter name, for example, results in a failure of the parameter to be read and the development default gets used instead.
e.g. The report has a parameter 'Batch' with a default of 1234 and the user calls for <url>?batch=5678. The report will use 1234.
Any good ideas for suppressing the default in production?
Dynamically fetching the params the resource expects/has configured and comparing it to what you are providing is your best way however its not always possible.
Same issue with named queries, a missed param results in a null value instead of what you thought was provided. I do think in 8.3 with named queries IA handle this differently and better, but in 8.1 I did as follows -
Then I use a intermediary function like myLib.runNamedQuery(args, *kwargs) that eventually feeds system.db.runNamedQuery but will run a param check on the path first. At that point handle it how you want - throw an error to be strict, or log a warning so that when you don't get a result you expect you can see it in the logs.
IIRC I think there was a recent post about report params not being exposed and so you cannot do this before opening the report. In vision you can do it after a report viewer is open Get List of Report Parameters but ideally you'd probably like to compare prior.
With vision window opening there's no real way for the user to easily just open up a window with their own params as it is with perspective so once your navigation is setup it "just works" unless you make the mistake. But vision also yells at you for providing params on a window that don't exist so it's obvious
I don't know what the solution for perspective would be espeically in the event a user is manually entering a URL.
