When using ASP.NET(aspx page) I can use Respone.Write to send information to
the browser..
I know that it would be better to use Windows-application event handle log
but just for
learning assume that I want to send ex.Message to the browser when an
exception occur how can I do that.
I tested to use Respone.Write but that was not possible ?
[WebMethod]
public decimal HowMuchWillItCost(string productName, int howMany)
{
SqlConnection sqlConn = null;
try
{
ConnectionStringSettings cs =
ConfigurationManager.ConnectionStrings["NorthwindConnectionString"];
string connString = cs.ConnectionString;
sqlConn = new SqlConnection(connString);
SqlCommand sqlCmd = new SqlCommand();
sqlCmd.CommandText = string.Format(@"select UnitPrice from Products
where productName = {0}", productName);
sqlCmd.Connection = sqlConn;
sqlConn.Open();
decimal price = (decimal)sqlCmd.ExecuteScalar();
return price * howMany;
}
catch (Exception ex)
{
return 1;
}
finally
{
if (sqlConn != null)
sqlConn.Close();
}
}
//Tony
> When using ASP.NET(aspx page) I can use Respone.Write to send information
> to the browser..
Avoid at all costs using Response.Write in an ASP.NET app - it's *ALWAYS*
the wrong solution, and completely unnecessary. ASP.NET is
object-orientated, not linear like ASP Classic, and if you use
Response.Write you often have very little control over where in the rendered
HTML stream the text you're injecting will actually appear. Use this
instead:
http://www.google.co.uk/search?aq=f&sourceid=chrome&ie=UTF-8&q=asp:Literal
> SqlConnection sqlConn = null;
> finally
> {
> if (sqlConn != null)
> sqlConn.Close();
> }
> }
Consider the using (.....) structure for this sort of coding:
http://msdn.microsoft.com/en-us/library/yh598w02.aspx
> I want to send ex.Message to the browser when an exception occur how can I
> do that.
> catch (Exception ex)
> {
> return 1;
> }
The problem here is that you are catching the exception, but then doing
nothing with it... Presumably this is because you are using a web service.
Also, what happens if the HowMuchWillItCost web method actually returns a
value of 1? How can you tell the difference?
Exception handling in web services can be tricky, depending on your
requirements. Fortunately, you're not the first person to encounter this,
and there are hundreds of articles on the web describing various techniques:
http://www.google.co.uk/search?rlz=1C1CHMA_en-GBGB328GB328&aq=1&oq=%22web+service%22+%22exception+handling%22&sourceid=chrome&ie=UTF-8&q=web+service+exception+handling+.net
--
Mark Rae
ASP.NET MVP
http://www.markrae.net
> Avoid at all costs using Response.Write in an ASP.NET app - it's
> *ALWAYS* the wrong solution, and completely unnecessary.
An addition to Mark's comments:
The exception to using Response.Write "in ASP.NET" is compiled controls.
Not user controls, as they are part of the ASP.NET tagged world, but
server controls that you compile into a library. The reason for this is
you need to fully render the control as it is called from the "page". By
using Response.Write, you output the content to the Response stream at
the point when it is called.
The big key here is "do I need to directly output to the Response
stream". In 99.999% of the cases, the answer is most likely NO.
When you use Response.Write in a page, you are outputting to the stream
when the event handler is called. If you put it in Page_Load, for
example (or even a button click, et al), you end up with your crud at
the top of the page, like so:
My Crud Here
<html>
Not very pretty or pratical.
Now, if you wanted to rewrite the ASP.NET engine and output all of the
HTML by hand, then Response.Write might work.
NOTE: If you are still insistent on writing ASP in ASP.NET (not a good
idea, imo), you can embed code in the page. But this leads to a
combination of concerns instead of a separation of concerns. You also
end up with a more tightly coupled application in most cases. Ouch!
Peace and Grace,
--
Gregory A. Beamer (MVP)
Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com
*******************************************
| Think outside the box! |
*******************************************
> Hello!
>
> When using ASP.NET(aspx page) I can use Respone.Write to send
> information to the browser..
This is not a good idea unless you understand how to control the
Response stream. I have seen Response.Write used in many cases, and I am
not sure I have ever seen it used correctly. In general, when it is
used, the developer ends up reinventing the rendering engine (good case)
or writing an ASP page in an ASPX page, which is nasty.
> I know that it would be better to use Windows-application event handle
> log but just for
> learning assume that I want to send ex.Message to the browser when an
> exception occur how can I do that.
> I tested to use Respone.Write but that was not possible ?
If you want to handle errors in your web services, you need to account
for them in your WSDL. Soap Exceptions are part of the framework and are
much better solutions to solving the exception problem than outputting
to the Response stream.
For the record, you can use the Response stream in a web service, but
you end up having to rewrite part of the "engine" in the process. You
cannot easily use a hybrid approach, which is what you are attempting.
Inside web service we can throw exception details by mentioning error
message, type of error, actor (page which caused the error) and inner
exception. For example
string AnErrorString = "a custom error message";
SoapException ex = new
SoapException(AnErrorString,SoapException.ClientFaultCode);
throw ex;
On client side we can access it by:
catch (SoapException soapExc)
{
lblExceptionMessage.Text = soapExc.Message;
}
For further examples you can refer
http://www.codeproject.com/KB/WCF/WCF_Web_Service_Remoting.aspx
--
Abdul Sami
"Tony Johansson" wrote:
> .
>
One approach is to change HowMuchWillItCost to return an object
public class CostResult
{
public bool HasError {get; set;}
public decimal Cost {get; set;}
public string ErrorMessage {get; set;}
}
Create a CostResult before the try... catch... block, set appropriate
values within the block, return it below the block.
A little more trouble to unpack on the client, but very clear whether
or not the call succeeded.