I was reading the documentation for cfthrow and came accross this
When to use the cfthrow tag
Use the cfthrow tag when your application can identify and handle
application-specific errors. One typical use for the cfthrow tag is in
implementing custom data validation. The cfthrow tag is also useful
for throwing errors from a custom tag page to the calling page.
For example, on a form action page or custom tag used to set a
password, the application can determine whether the password entered
is a minimum length, or contains both letters and number, and throw an
error with a message that indicates the password rule that was broken.
The cfcatch block handles the error and tells the user how to correct
the problem.
Have I been doing it wrong all this time or is this just a terrible use-case?
I was taught that exceptions shouldn't be used to handle regular application flow but for stuff that is somewhat out of your control. For example, a file being locked when you go to write to it.
A user breaking a password rule doesn't quite sound like something that's out of your control.
That is a poor example not a poor use case. I personally would pass in the parameters to a validation function and return a result that contained a pass or fail and a collection of failure messages to display to the user.
How I use exceptions is as follows.
Within functions. Let's say that you have a function that you are getting some data from the database and you are then constructing a structure from it. If the query returned has no values you have several options:-
You could return an empty structure and let the calling code deduce the problem from the fact the structure is empty. This is not ideal because then the application has to have complicated logic to address the missing data.
You could return a more complex datatype where one property is whether the process went ok and the actual data. Again this is not optimal as you have to then make this access the property on every call when the majority of the time you have data and again your application is dealing with this issue.
Or you could raise a custom exception with cfthrow indicating that there is no record that matches. This then means that you can choose to ignore the prospect of this error happening and let it bubble up to the onError handler or you could surround it in a try catch statement and deal with it there and then. This keeps your API clean and sensible.
Wrapping external errors let's say that you connect to an external API using cfhttp over https. Now this requires installing the certificate in your keystore otherwise it throws an error. If this certificate gets updated then it will start erroring again. In this instance I would wrap the call in a try catch and should this be the error I would wrap that in my own custom exception with a message detailing that we need to update the cert in the keystore so that any developer debugging it knows what to do to fix it without having to work it out. If it is not that particular error then I would cfrethrow it so that it bubbles up and is dealt with by whatever exception handling logic is above the call.
These are just a few examples, but there are more. To summarise I would say that throwing exceptions is a way of communicating up through the tiers of an application when something has occurred that is not the hoped for behaviour while keeping your API/Application logic clean and understandable.
It's really up to your discretion. It's extremely common in many languages to use exceptions for everything, including input validation.
Importantly, exceptions have nothing to do with something being in your control or not. For example, suppose that you have a fairly long and complicated module that uploads a file. There are many fail points in something like that: the file could be too big, the file could be the wrong format, etc. Without exceptions your only option is a lot of if/then checks and some kind of status return at the very end. With exceptions, all you have to do is use a set of cfthrows:
<cfthrow type="FileUpload.TooBig" message="The file size was #FileSize#, but the maximum size allowed is #MaxFileSize#">
<cfthrow type="FileUpload.WrongType" message="The file type was #FilType#, but the accepted types are #AcceptedTypeList#">
Then, whatever is calling the file upload function can catch either with <cfcatch type="FileUpload"> or catch a specific one (e.g. <cfcatch type="FileUpload.WrongType">).
Also, technically a user breaking a password is out of your control, in the sense that the user has determined the value for the password. That said, I loathe password rules as invariably they make it harder, not easier, to maintain security.
Related
Is it possible to throw an exception in a Logic App?
Specifically, I'm trying to throw an exception inside of a scope. Then in the run after of the scope I'd check if it failed and inspect it for errors. I tried using a terminate inside of a scope, but that terminates the entire logic app run.
As an updated solution we can use Terminate control, Terminate control has 3 status: Failed, Canceled, and Succeeded.
Quick Answer (TL;DR)
Problem: MSFT Azure logic app throwing exceptions
Workaround: Use logic app Scope element to simulate throwing exceptions
Create a scope element to use as your "try-catch" block
Force the scope element to fail with an invalid command to simulate an exception
Allow the scope element to fail naturally and that will count as an exception too
Detailed Answer
Context
MSFT Azure logic app workflows
live version as of 2020-06-14
Problem
Scenario: Developer wishes to throw an exception or use try-catch semantics in a logic app
Solution
As of this writing, the live version of the product does not support this feature. There is a workaround.
Workaround
Use logic app scope element
add a conditional statement inside the scope element
If the conditional statement meets the failure condition, force an exception with a deliberately invalid command
for example create a variable assignment with the value int('__ERROR__')
If the conditional statement does not meet the failure condition, do nothing
The rest of the logic app consists of two paths
The first path runs on the success of the scope element
The second path runs on the failure of the scope element (failed, skipped, timed out)
Example
Create a scope element as a "try-catch" block
Create a variable compose element with an invalid command
int('__ERROR__') ## this will cause the enclosing scope to fail
## the string __ERROR__ cannot be cast to integer
Respond to exit status of the Scope element enclosing your exception
See also
related SO answer about forcing exceptions https://stackoverflow.com/a/61101945/42223
No, there is no Action or Connector directly analogous to something like a throw in C#.
The closest you can get right now would be to do something like use another LogicApp instead of a scope from which you can return a specific status code.
It seems like there still is no option for this inside Logic App or its little brother Power Automate / Microsoft Flow.
The way I have come up with and have used in some flows, is I simply add an action for something I know for a fact will fail.
The simplest (and probably the cheapest as the built-in actions cost less in Logic Apps, even if we are talking fractions of a dollar here either way) is probably to initialize a variable, e.g. called ThrowException with type of integer.
Then a "Set variable" action is added wherever I want my flow to fail, where I set the value (remember it is of type integer) to any string expression. I simply use the expression string('Exception').
Simple example screenshot
Since the value is set via an expression this is still a valid template, but will fail upon runtime when the value is actually being set.
After this, simply use parallel branches, with appropriate Run After settings, as usual.
So, I'm building a plugin for logstash and I can't seem to find any documentation on how I should handle exceptions thrown and or rescued. So far, and similar to grok, we're adding a event["tag"] = ["_filter_error"], but in regards to metadata like a stacktrace, error type, etc... where should those live, or should they be omitted?
This is sort of a case-by-case question, so admittedly hard to answer. But I'll share how we ended up doing it so it might help someone.
Rescue all the exceptions (LogStash will hang otherwise)
Add a tag to the event event["tags"] = ["_filter_error"] so these can be query-able down the road
Ignore the stacktrace and error message (our decision - basically use the tag instead)
Use a single field as metadata about the tag we added to the event. For instance, if our filter blew up altogether, honey-badger it and move on. If our filter failed 1/2 through filtering, add as much data to the event as you can, add the tag in step 2, then create a metadata field (i.e. event["unknown_tags"] = [1,6,7] where our filter blew up at tags 1,6,7 but passed for everything else)
I was wondering how to make it so the rest of the program runs when one component fails to (and therefor the rest of the path that relied on this component is incapacitated as well). In other languages, this is equivalent to "catching an exception," but the added issue here is that I'm afraid that even if such a feature existed (cant find if it does), then the rest of the program would still try to run... Any advice would be very much appreciated. Thanks in advance!
LabVIEW doesn't have exception handling, but handles error in a different way: (nearly) all VIs accept an error cluster as input (and so should yours); if it is positive (an error occurred), the VI will return immediately, passing error as output, and next will get it as input, etc. This is called error.
As all these VIs transmit this cluster between each others you will get it in your top-level VI, so if error occurs you just have to cleanup stuff correctly it and exit.
Suppose I have a method that must return an object (say from a database layer) and takes as input some info about the requested object.
In the normal case, the method should return the object. But what happens if the precondition of the methods are not fulfilled by the caller; how should I (the code writer of the method) inform the caller?
Take for example the case that I should return information about the user from a db, and I take as input the username and the password. In the normal case I should return the User object. But what if the username and password are null, if they mismatch, if the password is too short... how should I inform the caller what is exactly the problem?
Normally I would have thrown an exception, but here - When to throw an exception? was suggested that it is a bad idea.
Should I put an errorDetail field in the User, or make a method checkInputData or getErrorStatus...
It sounds perfectly reasonable to throw an exception in this case. The method, which should be doing one thing and only one thing, is simply trying to fetch a user record from the database. If a precondition fails, give up. If the database errors out, give up. If no user is found, give up. Let the calling code deal with the consequences.
An exception is a perfectly acceptable exit path for a method.
In the case of the precondition, it's not the method's responsibility to fix that. It's the calling code's responsibility. So throw an ArgumentException of some kind and let the calling code deal with it.
In the case of a database error, either catch it and throw a custom exception (something like an InfrastructureFailed exception) for the application to handle accordingly. Basically the application needs to tell the user that there are technical difficulties and to please try again later.
In the case of no user being found, that sounds like a failed login. Throw some kind of SecurityException and let the calling application handle it by notifying the user that the login has failed. (Don't be more specific. For example, don't tell the user that the username was fine but the password was bad. That's giving a malicious user more information than you want them to have. Just say that the login failed, nothing more.)
You also mention a case of a password being too short. I imagine that's something that should be validated before it gets to this point. In this case, that falls up under input checking for the method. So the preconditions fail and the method never even tries to get to the database. But "password is too short" probably isn't a good error to tell a user at a login prompt. Rather, that's for when they try to create the password.
One thing you shouldn't do is return null or an empty user object or anything like that. This puts the onus on the calling code to check if there was an error. Exceptions are a perfectly valid way of notifying calling code of an error. A "magic object" being returned is just like any other "magic string" in code, but worse because it leaks out of the method and into other code.
Now, this isn't always a complete rule, of course. It depends on the structure of the application. For example, if this is a web service or some other kind of request/response system then you might want to have a standard response object which would indicate failure. That assumes some application context around the method, though. And in that case you probably should still be dealing with multiple methods. The inner one (a domain logic method) would throw the exception, the outer one (an application UX-aware method) would catch the exception and craft an appropriate non-null response to the UI.
How you handle the exception is up to the logical structure of your application. But throwing and catching exceptions (keep in mind that "catching" is not the same thing as meaningfully "handling") is perfectly acceptable behavior.
Does it make sense to return some kind of sentinel value? If so, consider using that. Otherwise, why not throw an exception?
I would return an object that contains both a user (null in the case of an error), a success flag (false in the case of an error) and a list of strings as validation messages (on error, a list of reasons why it failed).
Adding an errorDetail field on the user object doesn't make sense since that is not really a property of the user object. It's just part of this return data from the method. This path leads to objects with muddles properties that are only used by certain methods.
I found questions here Should a retrieval method return 'null' or throw an exception when it can't produce the return value? and Should functions return null or an empty object?, but I think my case is quite different.
I'm writing an application that consists of a webservice and a client. The webservice is responsible to access data, and return data to the client. I design my app like this:
//webservice
try
{
DataTable data = GetSomeData(parameter);
return data
}
catch (OopsException ex)
{
//write some log here
return null;
}
//client:
DataTable data = CallGetSomeData(parameter);
if(data == null)
{
MessageBox.Show("Oops Exception!");
return;
}
Well, there is a rule of not returning null. I don't think that I should just rethrow an exception and let the client catch SoapException. What's your comment? Is there better approach to solve this problem?
Thank you.
In your case, an exception has already been thrown and handled in some manner in your web service.
Returning null there is a good idea because the client code can know that something errored out in your web service.
In the case of the client, I think the way you have it is good. I don't think there is a reason to throw another exception (even though you aren't in the web service anymore).
I say this, because, technically, nothing has caused an error in your client code. You are just getting bad data from the web service. This is just a matter of handling potentially bad input from an outside source.
Personally, as a rule of thumb, I shy away from throwing exceptions when I get bad data since the client code can't control that.
Just make sure you handle the data == null condition in such a way that it doesn't crash your client code.
In general i try to design my webservices in such way that they return a flag of some sort that indicates whether there was a technical/functional error or not.
additionally i try to return a complex object for result not just a string, so that i can return things like:
result->Code = "MAINTENANCE"
result->MaintenanceTill = "2010-10-29 14:00:00"
so for a webservice that should get me a list of dataEntities i will return something like:
<result>
<result>
<Code>OK</Code>
</result>
<functionalResult>
<dataList>
<dataEntity>A</dataEntity>
</dataList>
</functionalResult>
</result>
so every failure that can occur behind my webservice is hidden in a error result.
the only exceptions that developers must care about while calling my webservice are the exceptions or errors that can occur before the webservice.
All the WebServices that I've used return objects, not simple data types. These objects usually contain a bool value named Success that lets you test very quickly whether or not to trust the data returned. In either event, I think any errors thrown should be untrappable (i.e. unintentional) and therefore signify a problem with the service itself.
I think there may be a few factors to consider when making a decision:
what is the idiomatic way to do this in the language your using (if it wasn't a webservice)
how good your soap/webservice library is (does it propogate exceptions or no)
what's the easiest thing for the client to do
I tend to make the client do the easiest, idiomatic thing, within the limitations of the library. If the client lib doesn't take care of auto restoring serialized exceptions I would probably wrap it with a lib that did so I could do the following.
Client:
try:
# Restore Serialized object, rethrow if exception
return CallGetSomeData(parameter);
except Timeout, e:
MessageBox.Show("timed out")
except Exception, e:
MessageBox.Show("Unknown error")
exit(1)
WebService:
try:
return GetSomeData(parameter) # Serialized
except Exception, e:
return e # Serialized
Your first problem is "a rule of not returning null". I would strongly suggest reconsidering that.
Returning a SoapException is a possibility, but like hacktick already mentioned, it would be better to return a complex object with a status flag {Success,Fail} with every response from the web service.
I think it all boils down to the question whether or not your client can use any info as to why no data was returned.
For example - if no data was returned because the (say sql) server that is called in GetSomeData was down, and the client can actually do something with that information (e.g. display an appropriate message) - you don't want to hide that information - throwing an error is more informative.
Another example - if parameter is null, and that causes an exception.. (although you probably should have taken care of that earlier in the code.. But you get the idea) - should have throw an appropriate (informative) exception.
If the client doesn't care at all why he didn't get any data back, you may return null, he'll ignore the error text anyhow and he's code will look the same..
If your client and service are running on different machines or different processes, it will be impossible to throw an error from the service and catch it on the client. If you insist on using exceptions, the best you can hope for is some proxy on the client to detect the error condition (either null or some other convention) and re-throw a new exception.
The general practice in handling exception is, when the sequence of flow is expected in the normal circumstance where as the sequence could not be completed due to non-availability of resources or expected input.
In your case, you still need to decide how do you want your client side code to react for null or exception.
How about passing in a delegate to be invoked when anything bad happens? The delegate could throw an exception if that's what the outside could would like, or let the function return null (if the outside code will check for that), or possibly take some other action. Depending upon the information passed to the delegate, it may be able to deal with problem conditions in such a way as to allow processing to continue (e.g. the delegate might set a 'retry' flag the first few times it's called, in case flaky network connections are expected). It may also be possible for a delegate to log information that wouldn't exist by the time an exception could get caught.
PS--It's probably best to pass a custom class to the problem-detected delegate. Doing that will allow for future versions of the method to provide additional information to the delegate, without breaking any implementations that expect the simpler information.
Exceptions are recommended in the same process space. Across processes, it is only through information that a success/failure is evaluated.
Since you are the client to your webservice, you can log the exception at the service layer and return null to the client, yet the client should still know if the CallGetSomeData returned null because a) data is not available, or b) there is a database exception as the table is locked. Hence its always good to know what has caused the error for easier reporting at client side. You should have a error code and description as part of your message.
If you are not consuming your webservice then you should definetly throw exception for the same reasons mentioned above, client should know what has happened and its upto them to decide to what to do with that.