I made a custom report in AX2012, to replace the WHS Shipping pick list. The custom report is RDP based. I have no trouble running it directly (with the parameters dialog), but when I try to use the controller (WHSPickListShippingController), I get an error saying "Pre-Processed RecId not found. Cannot process report. Indicates a development error."
The error is because in the class SrsReportProviderQueryBuilder (setArgs method), the map variable reportProviderParameters is empty. I have no idea why that is. The code in my Data provider runs okay. Here is my code for running the report :
WHSWorkId id = 'LAM-000052';
WHSPickListShippingController controller;
Args args;
WHSShipmentTable whsShipmentTable;
WHSWorkTable whsWorkTable;
clWHSPickListShippingContract contract; //My custom RDP Contract
whsShipmentTable = WHSShipmentTable::find(whsWorkTable.ShipmentId);
args = new Args(ssrsReportStr(WHSPickListShipping, Report));
args.record(whsShipmentTable);
args.parm(whsShipmentTable.LoadId);
contract = new clWHSPickListShippingContract();
controller = new WHSPickListShippingController();
controller.parmReportName(ssrsReportStr(WHSPickListShipping, Report));
controller.parmShowDialog(false);
controller.parmLoadFromSysLastValue(false);
controller.parmReportContract().parmRdpContract(contract);
controller.parmReportContract().parmRdpName(classStr(clWHSPickListShippingDP));
controller.parmReportContract().parmRdlContract().parmLanguageId(CompanyInfo::languageId());
controller.parmArgs(args);
controller.startOperation();
I don't know if I'm clear enough... But I've been looking for a fix for hours without success, so I thought I'd ask here. Is there a reason why this variable (which comes from the method parameter AifQueryBuilderArgs) would be empty?
I'm thinking your issue is with these lines (try removing):
controller.parmReportContract().parmRdpContract(contract);
controller.parmReportContract().parmRdpName(classStr(clWHSPickListShippingDP));
controller.parmReportContract().parmRdlContract().parmLanguageId(CompanyInfo::languageId());
The style I'd expect to see with your contract would be like this:
controller = new WHSPickListShippingController();
contract = controller.getDataContractObject();
contract.parmWhatever('ParametersHere');
controller.parmArgs(args);
And for the DataProvider clWHSPickListShippingDP, usually if a report is using a DataProvider, you don't manually set it, but the DP extends SRSReportDataProviderBase and has an attribute SRSReportParameterAttribute(...) decorating the class declaration in this style:
[SRSReportParameterAttribute(classstr(MyCustomContract))]
class MyCustomDP extends SRSReportDataProviderBase
{
// Vars
}
You are using controller.parmReportContract().parmRdpContract(contract); wrong, as this is more for run-time modifications. It's typically used for accessing the contract for preRunModifyContract overloads.
Build your CrossReference in a development environment then right click on \Classes\SrsReportDataContract\parmRdpContract and click Add-Ins>Cross-reference>Used By to see how that is generally used.
Ok, so now I feel very stupid for spending so much time on that error, when it's such a tiny thing...
The erronous line is that one :
controller.parmReportName(ssrsReportStr(WHSPickListShipping, Report));
Because WHSPickListShipping is the name of the AX report, but I renamed my custom report clWHSPickListShipping. What confused me was that my DataProvider class was executing as wanted.
I'm working off of the following example to implement editing of a cell in my grid when the cell is clicked:
http://demos.telerik.com/aspnet-ajax/grid/examples/dataediting/editondblclick/defaultcs.aspx
I'd like it to work just like in the example, but based on a single-click. I can't get it to work as I keep getting the following error buried away in Telerik.Web.UI.WebResource:
0x800a139e - Microsoft JScript runtime error: Sys.WebForms.PageRequestManagerServerErrorException: The string was not recognized as a valid format.
If anyone can lend any assistance, I will you owe you my first-born, as I am pulling my hair out trying to get this to work.
Thank you
Initially, the error was here but it didn't seem essential:
protected void detailsGrid_ItemCreated(object sender, GridItemEventArgs e)
{
if (e.Item is GridDataItem && e.Item.IsInEditMode)
{
((e.Item as GridDataItem)["detailsGridMonthOneCol"].Controls[0] as RadNumericTextBox).Width = Unit.Pixel(50); // ArgumentOutOfRangeException - Specified argument was out of the range of valid values
}
}
detailsGridMonthOneCol is the name of the column I double-clicked. This didn't seem essential, so I commented it out and that's when I got the following error:
Unhandled exception at line 15, column 16485 in http://localhost:63919/Telerik.Web.UI.WebResource.axd?_TSM_HiddenField_=RadScriptManager1_TSM&compress=1&_TSM_CombinedScripts_=;;System.Web.Extensions,+Version=4.0.0.0,+Culture=neutral,+PublicKeyToken=31bf3856ad364e35:en-US:10a773fc-9022-49ec-acd6-8830962d8cbb:ea597d4b:b25378d2;Telerik.Web.UI,+Version=2012.2.815.40,+Culture=neutral,+PublicKeyToken=121fae78165ba3d4:en-US:bd12f06c-2391-4523-868e-0017245d9792:16e4e7cd:ed16cbdc:f7645509:24ee1bba:e330518b:1e771326:8e6f0d33:6a6d718d:58366029:4b09f651:a2c5be80:874f8ea2:c172ae1e:f46195d3:9cdfc6e7:2003d0b8:c8618e41:e4f8f289
0x800a139e - Microsoft JScript runtime error: Sys.WebForms.PageRequestManagerServerErrorException: The string was not recognized as a valid format.
The code is buried away but here's where the exception gets thrown:
var e=this._get_eventHandlerList().getHandler("endRequest"),b=false;if(e){var c=new Sys.WebForms.EndRequestEventArgs(a,f?f.dataItems:{},d);e(this,c);b=c.get_errorHandled()}if(a&&!b)throw a}
In your Script Manager add a handler to the OnAsyncPostBackError="myScriptManager_AsyncPostBackError" and in code behind just put one breakpoint on the open curly brace of the method.
protected void myScriptManager_AsyncPostBackError(object sender, AsyncPostBackErrorEventArgs e)
{ // breakpoint this line.
}
doing this, probaly, this breakpoint will be hit and you could debug your code, and inspect who was thwrowing the exception.
This can help, but, the only way to help you, in fact, is if you provide the full source code. I suggest you to create another project, isolate the code that you want to work, and publish this code on github, ftp, etc.
Please, post your code and i will help.
The code is not really buried away. Javascript is showing you this error. However. the error is happening on the server side (Sys.WebForms.PageRequestManagerServerErrorException)
Check the Event Viewer (start => Run => eventvwr) it will show you more details of the error.
Is there a way to control the name of the MSTEST video recoding file names or the folder names with the test name. It seems to generate different guid everytime and thus very difficult to map the test with its corresponding video recording files.
The only solution I can see is to read the TRX file and map the guid to Test Name.
Any suggestions ??
If you're not opposed to doing it by hand, it's pretty easy. I encountered the same problem, and needed them to be somewhere predictable so I could email links to the videos. In the end my solution just ended up being to code in the functionality by hand. It's a bit involved, but not too difficult.
First, you'll need to have Expression Encoder 4 installed.
Then you'll need to add these references to your project:
Microsoft.Expression.Encoder
Microsoft.Expression.Encoder.Api2
Microsoft.Expression.Encoder.Types
Microsoft.Expression.Encoder.Utilities
Next, you need to add the following inclusion statements:
using Microsoft.Expression.Encoder.Profiles;
using Microsoft.Expression.Encoder.ScreenCapture;
Then you can use [TestInitialize] and [TestCleanup] to define the correct behavior. These methods will run at the beginning and end of each test respectively. This can be done something like this:
[TestInitialize]
public void startVideoCapture()
{
screenCapJob.CaptureRectangle = RectangleSelectionUtilities.GetScreenRect(0);
screenCapJob.CaptureMouseCursor = true;
screenCapJob.ShowFlashingBoundary = false;
screenCapJob.OutputScreenCaptureFileName = "path you want to save to";
screenCapJob.Start();
}
[TestCleanup]
public void stopVideoCapture()
{
screenCapJob.Stop();
}
Obviously this code needs some error and edge case handling, but it should get you started.
You should also know that the free version of Expression Encoder 4 limits you to 10 minutes per video file, so you may want to make a timer that will start a new video for you when it hits 10 minutes.
This is mod_perl2 on Apache 2.2, ActiveState Perl 5.10 for win32.
I override $SIG{__DIE__} and turn on DBI's RaiseError flag, which AFAICT from the docs, should call my override when a database call fails. It seems to almost always, except in one case, and I can't understand why.
My script has an our $page variable, and being mod_perl2, I can get at this from the override like so:
use Carp::Trace;
my $full_trace = Carp::Trace::trace;
$full_trace =~ m/^(ModPerl::ROOT::ModPerl::Registry::.*::)handler .*$/m;
my $page;
if (defined $1)
{
eval '$page = $' . $1 . 'page';
if (defined $page)
{
$json = 1 if defined $$page{json_response};
if (defined $$page{dbh})
{
my $errno = $$page{dbh}->state;
if ($errno ~~ $$page{error_handling}{allowed})
{
# allowed to let it go--no report, expected possible user error at some level that couldn't be caught sooner (usually db level)
my $errmsg = $$page{error_handling}{translation_map}{$errno};
if (defined $errmsg)
{
...
This works fine. Now, within that $page, I have an array ref of 'allowed' error values that I want to do something different with when they come back from the DB. When the DB throws one of these errors, I want to translate it into a user-friendly message, $r->print that in JSON, and stop execution (behaviour A). For some reason, it instead returns control to the script (behaviour B).
Here's the main part of my script:
{
$$page{error_handling}{allowed} = ['22007'];
$$page{json_response}{result} = $page->one_liner("select 'aa'::timestamp");
$$page{json_response}{test} = $$page{error_handling}{state};
}
$page->make_json; # just JSONifies $$page{json_response} and prints it
If I comment out the first line, I get a normal error (handling something unexpected) (behaviour C), which is what I expect, because I haven't added the error that's occurring to the list of allowed errors. What's really strange is, if I cut that first line and paste it into my $SIG{__DIE__} override, it works: the JSON response is overridden, printed, and execution stops before {test} is assigned (behaviour A). Stranger still, I can set {allowed} to any set of numbers, and so long as it contains '22007' in particular, I get behaviour B. If it doesn't, I get behaviour C. Even more strange, I can actually fill my override with anything (warnings, calls to CORE::die, etc.--as long as it compiles) and I get behaviour B still--even though the override no longer contains any of the code that would make it possible! Also I don't get any of the expected results of the calls to warn and CORE::die, just silence in the logs, so I can't even attempt to manually trace the path of execution through my override.
I have restarted Apache2.2 in between every script save. I have even moved the override to the same script file as the script itself, out of the module where it normally is, and commented out the entire module file where the override normally is, and restarted.
If I take out that first line, or take '22007' out of it, I can warn and die and otherwise manually debug all I like, and everything works as expected. What is it about '22007' that it never outputs anything different despite server resets? There are no references to '22007' anywhere else in the entire project, except the translation map, and I can delete it from that file entirely and restart and the result is no different. It's behaving as if it has cached my override from earlier in the day and will never ever forget. It's not a browser cache issue either, because I can add random query strings and the results are no different.
This is the strangest and most frustrating mod_perl2 experience I've ever had, and I've run out of ideas. Does anybody have any hints? The only thing I can think of is that it's a caching problem, yet I've restarted the service countless times.
Since it was the end of the day I thought I would try fully restarting the server computer, and it still didn't change anything. I even, before restarting the server, changed the only line where {state} is assigned to this:
$$page{error_handling}{state} = 'my face'; # $errno;
And yet, the output afterwards had {test} as '22007', which is what it should be only if I had left = $errno intact.
Even if it was, say, the reverse proxy it goes through doing the caching, this situation doesn't make sense to me, since the request can be different. After a full server restart, how can it still be assigning a value that is no longer in the code, i.e., how can it be using my old $SIG{__DIE__} override after a full restart, when it no longer exists in any file?
Update: I also tried changing the allowed errors to '42601' and changing the db call to 'select', which produces that error code, but did not add it to the translation map. It still gives me behaviour B, setting {state} to '42601', so it's not specific to '22007'. Any error code that is put into {allowed}, if that error actually occurs, it's running the old version of the override. Cause an error that's not in {allowed} and it runs the current version. But how does it know whether the current error is in {allowed}, or that that even means anything, before getting to the override? (Because the override is the only place where {allowed} is grepped for the current error.)
This is my temporary workaround, but I would like to solve the mystery and not have to add the extra line everywhere I have a DB call with allowed errors.
package MyModule::ErrorLogging;
sub InsanityWorkaround # duplicates part of $SIG{__DIE__} override for allowed errors
{
my ($page) = #_;
my $r = $$page{r};
my $errno = $$page{error_handling}{state};
if ($errno ~~ $$page{error_handling}{allowed})
{
# allowed to let it go--no report, expected possible user error at some level that couldn't be caught sooner (usually db level)
my $errmsg = $$page{error_handling}{translation_map}{$errno};
if (defined $errmsg)
{
use JSON::XS qw(encode_json);
$$page{json_response} =
{
error => $errmsg,
};
my $response = encode_json($$page{json_response});
$r->content_type("application/json");
$r->print($response);
exit(0);
}
else
{
return 0; # get back to script where {state} can be checked and output can be customized even further
}
}
return;
}
Then my script becomes:
{
$$page{error_handling}{allowed} = ['22007']; # don't be bothered by invalid timestamp error
$$page{json_response}{result} = $page->one_liner("select 'aa'::timestamp");
MyModule::ErrorLogging::InsanityWorkaround($page);
}
This is giving behaviour A.
When validating data, I've gotten into a habit of doing the following:
Note: I don't really have individual booleans for each check. This is just for the example.
Another Note: any error handling during the tests are done properly. The ONLY exceptions thrown in the try-catch are my own.
try {
if (validCheckOne = false) {
throw new Exception("Check one is bad");
}
if (validCheckTwo = false) {
throw new Exception("Failed because of check2");
}
if(validCheckTen = false) {
throw new Exception("Yet another failure on your part: check10.");
}
} catch(Exception e) {
MessageBox.Show("Your stupid data is wrong! See for yourself: " + e.Message);
}
Is this bad practice? Does throwing Exceptions slow the program's execution or is inadvisable?
Personally I like throwing Exceptions for business rule validation (not so much for user input validation) because it forces the problem to be handled upstream. If my business objects returned some kind of validation result, it could be ignored by the caller. Call me a cowboy if you wish :)
Everyone here is repeating the phrase "exceptions are for exceptional circumstances", but that really doesn't give any understanding of why its bad to use them for unexceptional circumstances. I need more than that. Is the performance hit of throwing exceptions really that bad? Are there any benchmarks available?
I'm going to repeat the mantra here: throwing exceptions should be done in exceptional circumstances. Invalid entered data is really not that exceptional.
I support MusiGenesis's answer.
Additionally...
The performance of throwing an exception is a thousand instructions. It's nothing compared to end-user time, but in inner code it is slow.
An additional problem is that, using Exceptions, your validation is limited to reporting the first failure (and you will have to do it all again next time to find the next failure).
In addition to the oft-repeated statement that "exceptions are for exceptional circumstances", here's an additionally clarifying rule I've come to like:
If the user caused it, it's not exceptional.
Exceptions are for system-side things (servers going down, resources being unavailable), not for the user doing odd things, because all users do odd things.
It depends - if you are expecting the data to be there and NOT having the data is unexpected, then throwing an exception is OK. Throwing an exception is very expensive (slow) but is the best way to handle unexpected circumstances.
In the title you call it "validating" data. That can happen on several levels. In (near) the GUI where you are checking user entered data, you should be expecting errors and have ways to report the errors back. Exceptions are inappropriate in this case.
But Data Validation can also happen at other boundaries, say between business-rule classes. There, errors in the data are uncommon and unexpected. You should throw when you detect one.
So maybe in some languages exception throwing and catching is "costly" but in other languages, throwing and catching exceptions is exactly what's called for.
In Smalltalk, for example, one could quickly build a multi-tiered exception catching solution. The validation pass could collect up any number of exceptions representing EVERYTHING that's wrong with a particular input data set. Then it would throw them ALL up to a higher-level catcher, responsible for formatting up a human-readable explanation of, again, EVERYTHING that was wrong with the input. In turn it would throw a single exception further up the chain, along with that formatted explanation.
So... I guess what I'm saying is, exceptions are only bad to throw if you've got no exception handling architecture supporting catching them and doing reasonable things with them, and all your catcher is going to do is EXIT or do something else equally inappropriate.
This is bad behavior. Exceptions are for Exceptional conditions. They take resources to generate the stack etc. Exceptions should not be used to dictate process flow.
In general it is inadvisable to use Exceptions to implement conditional flow. It would be better to do something like this
error = false;
while(true) {
if(validCheckOne == false) {
msg = "Check one is bad";
error = true;
break;
}
if(validCheckTwo == false) {
msg = "Check two is bad";
error = true;
break;
}
...
break;
}
if (error) {
..
}
You should throw an exception when there is a situation you can't do nothing about it. Higher layers of software would have a chance to catch the exception and do something about it - even if that is simply crashing the application.
I would suggest that using exceptions as described in the question (for flow control within a function) is wrong not usually the best idea. I'd go further and saying validation throwing exceptions isn't the best approach; instead return a Boolean and store a list of validation error messages that can be accessed. An accompanying save method could/should throw an exception if it is called on an invalid object.
Thus if validate fails validation error messages can be displayed to the user (logged, returned. whatever). If validation passes then you can call save.
If you call save on an invalid object then get get an appropriate exception.
Another potential problem with your example code (depending on requirements of course) is it only throws the first validation error that occurs. Imagine this from a users POV:
Click save
Get an error message
Correct error
Click save again
Get a different error message. Annoying.
As a user I'd prefer to get all validation errors returned at once so I can correct them all before trying again.
I generally agree with the "exceptions should be exceptional" rule, but I might make an exception (ha!) for Python, where it can be both efficient and considered good practice to use try ... except to control flow.
See Using Exceptions For Other Purposes, for example.
This question is still interesting, mainly because of the answers.
When it comes to exception, there is a lot of arguments involved. We can defend a point to any direction we want to, from performance to exception philosophy. And they all sounds right to me.
But sometimes we have to stick to a direction. In this case, I think it's the validation itself.
When we want to validate something we also want to know (to log, or to show the user) whats wrong when the parameter is invalid. Even thought there are layers of validation such as Business Validation mixed with User Input validations.
For instance, when dealing with user input, a lot of weird cases can happen. A pasted data from a website full of hidden char (\t \n etc), typos, and a really huge kinds of cases that a specific exception could allow further analysis or message to the uses much more precisely than a simple "false" return.
When you go to the grocery and ask the seller if he's got cheese, and the seller replies with no, would that be an unexpected or exceptional response?
What about if you do the same but the seller just looks at you and does not respond!
Another example, you are talking to your friend and ask if there is something wrong, you may get 2 responses:
They tell you that they are sad because of something.
Or they just look at you and say nothing, turn their back and walk away and you are sure that this means you're in deep trouble :)
Same way with exceptions, unexpected behavior is an exception, but an invalid but expected response should not - IMHO - throw exceptions.
I often write similar code for validation, especially in express.js, and similar request/response loop style applications. When something is invalid, I throw a ValidationError, it's caught by the top level error handler, which knows to send a 422 response with the additional information that's attached to the ValidationError.
It's a very convenient way to handle validation. You don't have to pass around an error object (potentially up through a dozen stack frames, in some cases). And it's a simple and consistent way to trigger an invalid input response. I haven't experienced any serious problems with this approach.
I've thought about the "don't use exceptions for flow control" maxim in relation to this practice, and decided the benefits outweigh any disadvantages. I would say if you understand the reasoning behind "don't use exceptions for flow control", but you determine that it's a good idea anyway in a certain case, then go ahead and do it. We don't need to be too dogmatic about these things.
Throwing exceptions is relatively slow, but that will only matter if you're doing it repeatedly in a loop.
It really only matters if your data validation is in a tight loop. For most cases, it doesn't matter what you choose as long as you are consistent in your code.
If you have a lot of code that looks like your sample above then you might want to clean it up by introducing a helper method to throw...
private void throwIf( bool condition, String message )
{
if( condition )
throw new ApplicationException( message );
}
(also, doing this will help zero in on errors such as "validCheckOne = false" versus "validCheckOne == false" :)
Well, i know it's an old question. But i'll let my opinion here for the googler's who falled here like me:
If you are using a language with a bad try/catch support AVOID
THROWING exceptions for data validation;
DO NOT THROW a exception that will not be handled by the caller or
alserwhere;
DO NOT THROW a exception if you need to validate the rest of the received data;
You can THROW a exception in cases where the code block cannot continue
without the invalid data; And if you do not interrupt the process you
can get a unhandled exception;
An example:
/*
* Here it's a common problem i have: Someone pass a list of products i need to
* retrieve from the database and update some information;
*/
//This is a class to represent the product
function Product(id, name, price) {
this.id = id;
this.name = name;
this.price = price;
}
//This is an example function to retrieve the product from the database
function findProductInDatabase(productId) {
//If the product exists on the database, the function will return it
if (productId == 12) {
var product = new Product(12, "Book", 20.5);
return product;
}
//If the product do not exists, it will return null
return null;
}
//This is a function that will receive the productID and will update the received parameters
function updateProduct(productId, newProductName, newProductPrice) {
var productFromDatabase = null;
var errorMessage = "";
//Retrieve the product
productFromDatabase = findProductInDatabase(productId);
//If the product do not exist, i need to interrupt de method imediatily and alert the caller
if (!productFromDatabase) {
throw "Product not found";
}
//Validate the other parameters, but in this case i can validate all the parameters
if (newProductPrice < 10) {
errorMessage += "the price is too low";
}
if (newProductName.includes("<")) {
//If already has a error message in the variable i append " and " to the message make sense
if (errorMessage) {
errorMessage += " and ";
}
errorMessage += "the new name has invalid characters";
}
if (errorMessage) {
//if theres any error, i will throw a exception with the messages
throw errorMessage;
}
}
//This parte is where the method id called;
try {
updateProduct(9, "Book", 10.5);
} catch (exception) {
console.log("Case 1: " + exception);
}
try {
updateProduct(12, "<Book", 9);
} catch (exception) {
console.log("Case 2: " + exception);
}
In test, sure, but in a live environment, you'd hope they're never raised.
You'd hope to refactor your code to the extent that all data into your system are validated at source, and either the user, or the system that generated the input to your system, is notified of the issue.
Exceptions should occur if you've missed something and should be a fallback that is handled gracefully.
You could store anything that's causing these exceptions separately, so that they don't make it into your system without being checked over first.
You don't want, e.g. an invalid value that falls outside a range of values to skew your results.