Before my main phing task runs, it first checks that all required properties have been set. If a property is missing or invalid, it calls a FailTask to end execution - which works.
<if>
<equals arg1="${build.db.host}" arg2="" />
<then>
<fail msg="build.db.host is empty." />
</then>
</if>
Alas, the FailTask throws a BuildException (with the msg), which throws an 'error in IfTask' - both of which are displayed twice, with their backtraces, giving me a 60-line screen dump for a one line message!
Is there a way to suppress the backtraces, or to catch (and discard) the exceptions? Ideally, I'd see something like:
BUILD FAILED
/path/to/build.xml:728:6: build.db.host is empty
Total time: 0.3351 seconds
I'm running the latest version of Phing, from the commandline in Ubuntu 14.04.
The backtrace has been cleaned up as part of http://www.phing.info/trac/ticket/1087 (will be released in version 2.9.0). Thanks for the question!
Related
I have a route (with Camel 2.23.1) like:
from("file://not.existing.dir?autoCreate=false&startingDirectoryMustExist=true&consumer.bridgeErrorHandler=true")
.onException(Exception.class)
.handled(true)
.log(LoggingLevel.ERROR, "...exception text...")
.end()
.log(LoggingLevel.INFO, "...process text...")
...
(I tried it with just &bridgeErrorHandler, too, since according to the latest doc the consumer. prefix seems to be not necessary any longer.)
According to the doc of startingDirectoryMustExist:
| startingDirectoryMustExist | [...] Will thrown an exception if the directory doesn’t exist. |
the following exception is thrown:
org.apache.camel.FailedToCreateRouteException: Failed to create route route1:
Route(route1)[[From[file://not.existing.dir?autoCreate=false...
because of Starting directory does not exist: not.existing.dir
...
but, despite of the doc and the description of [consumer.]bridgeErrorHandler it's propagated to the caller, i.e neither "exception text" nor "process text" are printed.
There is a unit test FileConsumerBridgeRouteExceptionHandlerTest that covers consumer.bridgeErrorHandler, so I think this works basically. Can it be that [consumer.]bridgeErrorHandler doesn't work in conjunction with the exception thrown by startingDirectoryMustExist?
Do I have to write my own [consumer.]exceptionHandler as mentioned in this answer to "Camel - Stop route when the consuming directory not exists"?
There also a post on the mailing list from 2014 that reports similar behaviour with startingDirectoryMustExist and consumer.bridgeErrorHandler.
UPDATE
After TRACEing and debugging through the code I found that the exception is propagated as follows:
FileEndpoint.createConsumer()
throw new FileNotFoundException(...);
--> RouteService.warmUp()
throw new FailedToCreateRouteException(...)
--> DefaultCamelContext.doStart()
(re)throw e
--> ServiceSupport.start()
(re)throw e
I couldn't find any point where bridgeErrorHandler comes into play.
Setting breakpoints on BridgeExceptionHandlerToErrorHandler's constructor and all of its handleException() methods doesn't stop at any of them.
Am I still missing something?
You should use the directoryMustExist option instead, then you can have the error during polling, which is where the bridge error handler can be triggered. The startingDirectoryMustExist option is checked during creating the consumer and therefore before the polling and where the bridge error handler operates.
See also the JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-13174
I'm making a custom plugin to query a database for user info to aide customer support. My backend is slack.
Everytime I start the bot command I'm greeted with:
Computer says nooo. See logs for details:
catching classes that do not inherit from BaseException is not allowed
I'm not sure if this is warning me that I'm attempting to catch an exception that isn't a BaseClass in my code or if an unknown exception was raised and caught elsewhere outside of my plugin.
To debug I tried:
try:
do_the_thing()
except (TypeError, ValueError) as e:
return('Something went wrong.')
I also tried:
try:
do_the_thing()
except Exception as e:
return('Something went wrong.')
And I still get the errbot admonition. Note that the command still runs and does the right thing where there is no exception raised by do_the_thing().
It means that:
Somewhere in your code you have an except ... statement where the exception ... (or one of the exceptions in the sequence ...) is not a subclass of BaseException, and
An exception is being thrown that is caught by that except ... statement.
The TypeError can be raised only when an exception is actually thrown because the names you give to except ... must be evaluated for their current values at that time; just because TypeError referenced a particular class at one point in the program's execution doesn't mean it won't be changed later to reference another object (though that would be admittedly perverse).
The Python interpreter should be giving you a full traceback of the exception; the first thing you need to do is find this. It could be occurring in one of two situations. (This is for single-threaded programs; I'm assuming your program is not multithreaded.)
During the execution of your program, in which case the program will be terminated by the exception, or
During finalization of objects (in their __del__(self) functions) in which case the error will be printed to stderr.
In both cases there should be a stack trace, not just the error message; I've confirmed that at least on Python ≥3.4 a stack trace is printed out for case 2.
You then need to follow this stack trace to see where the problem lies. Remember that the names you give to except ... are variables (even things like TypeError) that can be reassigned, so that you could conceivably be dealing with a (perverse) situation like:
TypeError = False
try:
...
except TypeError:
...
But more likely it will be something obvious such as:
class MyException: # Doesn't inherit from Exception
...
try:
...
except MyException:
...
There is one special case you need to be aware of: if you are seeing messages to stderr (case "2. During finalization," above) printed out as your program exits that means that the exception was thrown during cleanup as the interpreter shuts down, where random variables throughout the program may have already been set to None as part of the cleanup process. But in this case your program should still exit successfully.
I'm currently trying to configure the Fiware Iot Broker with the Configuration Manager (NECongMan) and Fiware Orion as the context producer. I'm having a problem with the NGSI10 subscribeContext operation.
This is the request sent to the IoT Broker:
<?xml version="1.0"?>
<subscribeContextRequest>
<entityIdList>
<entityId type="Room" isPattern="false">
<id>Room1</id>
</entityId>
</entityIdList>
<attributeList>
<attribute>temperature</attribute>
</attributeList>
<reference>http://localhost:1028/accumulate</reference>
<duration>PT1H</duration>
<notifyConditions>
<notifyCondition>
<type>ONCHANGE</type>
<condValueList>
<condValue>pressure</condValue>
</condValueList>
</notifyCondition>
</notifyConditions>
<throttling>PT5S</throttling>
</subscribeContextRequest>
The IoTBroker tries to contact Orion issuing a subscribeContextRequest but the duration string is changed:
<subscribeContextRequest>
<entityIdList>
<entityId
type="Room"
isPattern="false">
<id>
Room1
</id>
</entityId>
</entityIdList>
<attributeList>
<attribute>
temperature
</attribute>
</attributeList>
<reference>
http://192.168.16.178:8080/ngsi10/notify
</reference>
<duration>
P0Y0M0DT0H59M58.157S
</duration>
<notifyConditions>
<notifyCondition>
<type>
ONCHANGE
</type>
<condValueList>
<condValue>
pressure
</condValue>
</condValueList>
</notifyCondition>
</notifyConditions>
<throttling>
PT5S
</throttling>
</subscribeContextRequest>
But Orion gives an error (invalid payload: syntax error in duration string). Do you have any idea how to resolve the issue?
For one hour, Duration parameter may be P1H instead of PT1H, according to the ISO 8601 standard format, it seems like PT is used only to avoid ambiguity between P1M for one month and PT1M for one minute.
Hope it helps
Orion 0.26.1 (the last version in the moment of writing this) doesn't support decimal values (as 58.157) for seconds in duration strings. We have created an issue about that and our plan is to have it solved by next release (0.27.0).
Not sure if modifying the way IoTBroker behaves (in order to round up/down the secons to an integer in the request it sends to Orion) would be a valid workaround... I don't know the details about IoTBroker.
EDIT: the fix to support decimal fractions in the seconds field has been just implemented in Orion in develop branch, so it will be available in the next Orion version (0.27.0). Alternatively, you could download source code and build the code to get the fix right now.
I've got an image processing CFC to handle uploaded images. In the method, I'm creating an new image of the uploaded file with ImageNew() and then resizing it if needed (along with some other validation to make sure it's an image). Here's a snippet of the code:
<cftry>
<cfset ImageScaleToFit(#local.uploadedImage#, 72, "", "highestPerformance")>
<cfimage action="write" source="#local.uploadedImage#" destination="#local.newThumbName#" overwrite="yes" >
<cfcatch type="any">
<cfset local.response['catcher'] = #cfcatch.Detail#>
<cfset local.response['success'] = false>
<cfreturn local.response>
</cfcatch>
</cftry>
After I upoloaded the code to the production server it began throwing an error because "highestPerformance" isn't an available option for image compression on the production server.
As a backup for <cftry> exception handling I have the Application.cfc send me an email of the details while masking the errors from the user in the event the 'try' doesn't cathc the error.
Throughout the CFC the <cftry> catches the error and sends it back to my page. where it gets output to the console.
My question is, why does this particular block of code not work with <cftry> and the error gets sent directly to the exception handling in my Application.CFC?
Is there some sort of "error threshold" that my built-in exception handling can't handle?
BTW, "highPerformance" works for some reason even though the documentation at Adobe says "highestPerformance" is an available option...
EDIT:
Here's the error I'm getting from the Application.cfc
Could not initialize class javax.media.jai.JAI
And the stack trace:
ava.lang.NoClassDefFoundError: Could not initialize class javax.media.jai.JAI at coldfusion.image.Image.resizeImageWithJAI(Image.java:1189) at coldfusion.image.Image.resize(Image.java:1119) at coldfusion.image.Image.scaleToFit(Image.java:974) at coldfusion.image.Image.scaleToFit(Image.java:959) at coldfusion.runtime.CFPage.ImageScaleToFit(CFPage.java:6189) at cfspecials2ecfc103515531$funcUPLOADFILEXHR.runFunction(C:\cfc\thecfc.cfc:143) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418) at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47) at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:360) at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324) at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:59) at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192) at coldfusion.runtime.CfJspPage._invokeUDF(CfJspPage.java:2471) at cfspecials2ecfc103515531$funcMULTIUPLOAD.runFunction(C:\cfc\thecfc.cfc:32) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418) at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47) at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:360) at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324) at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:59) at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:463) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:453) at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:320) at coldfusion.filter.ComponentFilter.invoke(ComponentFilter.java:183) at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:282) at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:48) at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40) at coldfusion.filter.PathFilter.invoke(PathFilter.java:86) at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70) at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28) at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38) at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46) at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38) at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22) at coldfusion.xml.rpc.CFCServlet.invoke(CFCServlet.java:138) at coldfusion.xml.rpc.CFCServlet.doPost(CFCServlet.java:289) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89) at jrun.servlet.FilterChain.doFilter(FilterChain.java:86) at com.seefusion.Filter.doFilter(Filter.java:49) at com.seefusion.SeeFusion.doFilter(SeeFusion.java:1494) at jrun.servlet.FilterChain.doFilter(FilterChain.java:94) at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42) at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46) at jrun.servlet.FilterChain.doFilter(FilterChain.java:94) at jrun.servlet.FilterChain.service(FilterChain.java:101) at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106) at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286) at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543) at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203) at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:320) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428) at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:266) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
If you are using ColdFusion 8 make sure that you have all hotfixes and updates applied. CF 8 had a lot of major issues with image functions and tags, and if Java is causing the error underneath CF might not be able to catch it. Even if you aren't on CF 8 make sure that everything is updated.
The catch fails because the call to ImageScaleToFit() crashes the JVM. It sounds like your production sever is either missing the Java Advanced Imaging API (javax.media.jai.JAI) or it is not included in the classpath.
Further to my adventures with Erlang and ErlyDB. I am attempting to get ErlyDB working with BeepBeep
My ErlyDB setup works correctly when run outside of the BeepBeep environment (see Debugging ErlyDB and MySQL). I have basically take the working code and attempted to get it running inside BeepBeep.
I have the following code in my controller:
handle_request("index",[]) ->
erlydb:start(mysql,Database),
erlydb:code_gen(["thing.erl"],mysql),
NewThing = thing:new_with([{name, "name"},{value, "value"}]),
thing:save(NewThing),
{render,"home/index.html",[{data,"Hello World!"}]};
When I call the URL, the response outputs "Server Error".
There is no other error or exception information reported.
I have tried wrapping the call in try/catch to see if there is an underlying error - there is definitely an exception at the call to thing:new_with(), but no further information is available.
The stacktrace reports:
{thing,new,[["name","value"]]}
{home_controller,create,1}
{home_controller,handle_request,3}
{beepbeep,process_request,4}
{test_web,loop,1}
{mochiweb_http,headers,4}
{proc_lib,init_p_do_apply,3}
Use pattern matching to assert that things work up to the call to thing:new/1:
ok = erlydb:start(mysql,Database),
ok = erlydb:code_gen(["thing.erl"],mysql),
You include only the stack trace, look at the exception message as well. I suspect that the error is that you get an 'undef' exception. But check that it is so. The first line in the stack trace indicates that it is a problem with calling thing:new/1 with ["name", "value"] as argument.
It is slightly odd that you show one clause of handle_request that is not calling home_controller:create/1 as per {home_controller,create,1} in the stack-trace. What do the other clauses in your handle_request/2 function look like?