<cfcatch> not 'catching' an error - exception

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.

Related

File component's [consumer.]bridgeErrorHandler in conjunction with startingDirectoryMustExist

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

How to fail Phing without triggering backtrace

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!

Getting the line number or full stack trace on exceptions in a gremlin-groovy script

I have a gremlin-groovy script that traverses a database which is incredibly noisy. There are lots of cases with missing edges or properties. When I assume an edge or property exists and it doesn't an exception is thrown I get a very simple output like this:
javax.script.ScriptException: java.util.IllegalFormatConversionException: d != java.lang.String
I'd like to make it so when the script encounters a fatal exception, as the one above, it provides a stack dump or at least a line number so I can debug where it happened, similar to how java can print a full stack trace on fatal exceptions.
Any suggestions on how to get a better dump?
I recommend using the Gremlin terminal for this.
gremlin$ ./gremlin.sh
\,,,/
(o o)
-----oOOo-(_)-oOOo-----
gremlin> a bad thing
No such property: bad for class: groovysh_evaluate
Display stack trace? [yN] y
groovy.lang.MissingPropertyException: No such property: bad for class: groovysh_evaluate
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:50)
If you don't have this luxury (e.g. via a REST server), then you may want to place some intelligent 'printlns' in your traversal.
my.long.traversal.sideEffect{println 'I am here'}.is.very.long

BeepBeep and ErlyDB integration issue

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?

Error reading IPTC fields from JPEGs in .NET

I get the following exception when calling BitmapMetadata.GetQuery("/app13/irb/8bimiptc/iptc") on about 1% of JPEGs I have tried this on. What could be causing this and what can I do to fix it? (I have tried Googling but I can only find one relevant result asking the same question but with no answer.)
System.OverflowException:
The image data generated an overflow during processing. --->
System.Runtime.InteropServices.COMException (0x88982F05):
Exception from HRESULT: 0x88982F05
--- End of inner exception stack trace ---
at System.Windows.Media.Imaging.BitmapMetadata.GetQuery(String query)
at MyProject.ImageRecord..ctor(String file)
in C:\MyProject\ImageRecord.cs:line 93
The image data generated an overflow during processing.
Edit:
The exiv2 tool reports:
Error: Invalid Photoshop IRB data size 6372
My guess is that the Photoshop IRB data is longer than the header specifies.
At least this is what I can deduct by skimming over the source of Exiv2 (line 107):
http://dev.exiv2.org/repositories/entry/exiv2/trunk/src/jpgimage.cpp?rev=1146
But my understanding of c is not that good! :)
Error 0x88982F05 is only regular value-out-of-range error by WIC
Thus it can be easely handled by you. Also this might not be your only problem with IPTC query strings. Just try {} catch {} this section like this to graceful fallover
if (bitmapMetadata.GetQuery(MY_QUERY) != null &&) {
try {
... }
catch {}
Based on the information reported by exiv2, the size of the Photoshop IRB information is inconsistent with the overall size of the metadata.
If you wish to ignore the messages I would be more specific in the the type of exception you catch -- only ignore or report that particular COM Exception.
A couple of tools/resources out there:
http://blogs.msdn.com/rwlodarc/archive/2007/11/26/wic-tools-now-available.aspx
http://www.drewnoakes.com/code/exif/index.html