I'm looking to have more intuitive assert on my automated tests. I have one assert to verify if a error message is showing up, that is giving a little bit of headache.
Assert.assertNotSame((ExpectedConditions.textToBePresentInElementLocated(By.className("notification-title"), "Error message")), "Error message");
Any suggestion on how I can convert it?
It ended up being more simple than I thought:
assertThat((ExpectedConditions.textToBePresentInElementLocated(By.className("notification-title"), "Error message")), is(not("Error message")));
The notSame and False was confusing me :D
Related
I am new to Java and I am having trouble understanding a question. I am asked to select which of the following choices throws an exception. The options are:
1.) Integer.parseInt(" ")
2.) Integer.parseInt("54 ")
3.) Integer.parseInt("")
4.) Integer.parseInt("-54")
5.) Integer.parseInt("54n")
To answer this question, I need some explanations. What does the Integer.parseInt method do? Doesn't it turn an integer into a String? What sort of arguments are illegal to put inside this method. For example, are you allowed to include negative numbers? Strings? Or does it only accept integers?
I was also wondering if you could clarify what "throws an exception" means. I have a rough idea, I think it just means that if there is an error in your program, it gets terminated. Howevere, you can use the "try-catch-finally" method to try and predicate any errors your program would have and write a possible code to fix it?
Sorry for all the questions, I just want to understand this completely.
I have seen others write that if you don't do something with the exception then don't bother catching it. I can see point in that but what I am wondering is what entails "doing something with the exception"?
Does logging the error count as enough? I have some code where I want to return null if anything goes wrong. Is that reason enough to catch an exception?
This other question asks almost the same, but not quite. Rather, how do I demand that a goal succeeds deterministically (exactly once) and does not leave behind any choice points?
This is especially useful in the context of Prolog programs that are used as command-line tools: possibly read from standard input, take arguments, and write to standard output. In such a program, leaving a choice point after doing the work is invariably an error of the programmer.
SWI-Prolog offers deterministic/1, so one could write:
( deterministic(true)
-> true
; fail
)
Another, more portable way to achieve the same was suggested:
is_det(Goal, IsDet) :-
setup_call_cleanup(true, Goal, Det=true),
( Det == true
-> IsDet = true
; !,
IsDet = false
).
However, it seems useful to throw an error when this happens, but I don't know what this error would be. I looked quite carefully through the ISO error terms and I could not find an error that would obviously describe this situation.
Is it indeed better to throw an error, or should I just fail? If throwing an error is to be preferred, what would that error be?
EDIT: I am not sure what to because especially when side effects are involved, like writing something to standard output, it feels very wrong to have the side effect happen and then fail. It is almost necessary to rather throw an exception. This makes it also possible to decide that the remaining choice point is harmless (if not desirable) and just catch the exception, then write to standard error or return a different exit code.
But I really have no idea what describes the exception properly, so I don't know what term to throw.
Check out call_semidet/1 as proposed by Ulrich Neumerkel on the SWI-Prolog mailing list:
call_semidet/1 - clean removal of choice-points
In it, he proposes:
call_semidet(Goal) :-
( call_nth(Goal, 2)
-> throw(error(mode_error(semidet,Goal),_))
; once(Goal)
).
This proposed mode_error is a very good start.
In spirit, it follows the other errors: In this case, mode semidet is expected, and this is reflected in the thrown error term.
I am trying to do a simple addition of data to a database table (PostgreSQL). At first, I couldn't even get a simple
$my_item = $_item_class->new(...);
to work. I discovered I had spelled a field differently in my code from what I had in my "model" code.
But, now, this is working, but when I try:
$my_item->save;
it seems an exception is thrown. All this is occurring in an eval {...} structure and I would like to catch the exception and see what is going wrong, but I don't know how to do that.
Why would something like the "save" be failing here? I have checked everything, and all seems right (of course!).
And, how do I catch the exception that seems to be being thrown?
Thank you!
I figured all this out myself. It was simple. I had duplicated a field in my class somehow when I had done an edit to it. That was all. The class just had two identically named fields specified in the hash table in the class, both with identical characteristics. When I removed one of these, the code worked.
With regard to my second question about how to catch the exception, I had to learn how to have an
if ($#) {
.
.
.
}
right after my "eval {...}" structure. Because I am new to Perl, I didn't understand that. But, it was actually pretty easy to figure out. My problem was that I was working from some code as a model for me that didn't do that but named specific exceptions that were thrown in its "eval {...}" code. So, I thought that I had to have the names of exceptions that could be thrown by Rose::DB::Object calls, but I couldn't find any such exceptions in the documentation. When I learned about "if ($#) {...}", I was able to print out the reported exception in $# and from that I was able to see the problem with the duplicate field I mentioned above.
That was all there was to it. Everything is working just fine now.
I am writing some code and for now I am making some functions, but I'm not writing them yet. I'm just making an empty function that will do nothing yet. What I would like to do is throw an exception if the function is run, to prevent me from forgetting writing the function.
The easiest way is:
error('Some useful error message.')
Matlab is happier is you assign an identifer to you error message, like this:
error('toolsetname:other_identifying_information','Some useful error message here.')
The identifying information is reported with some of the error handling routines, for example, try running lasterror after each of the above calls.
You can also use:
throw(MException('Id:id','message'));
There is a nice feature to MException, it can be used as sprintf:
throw(MException('Foo:FatalError',...
'First argument of Foo is %s, but it must be double',class(varargin{1}) ));
As commented correctly by #edric, this sprintf functionality can be a double edged sword. If you use some of the escape characters, it might behave not like you want it.
throw(MException('Foo:FatalError',...
'I just want to add a \t, no tab!' ));
Did you read the MATLAB documentation for "Throwing an exception"?