Search Results

Search found 2244 results on 90 pages for 'exceptions'.

Page 17/90 | < Previous Page | 13 14 15 16 17 18 19 20 21 22 23 24  | Next Page >

  • Throw a long list of exceptions vs throw an Exception vs throw custom exception?

    - by athena
    I have an application which uses two methods of an API. Both these methods throw more than five exceptions each. So, if I just add a throws declaration then it becomes a list of more than ten. (My method cannot handle any of the ten exceptions) I have read that throwing a long list of exceptions is a bad practice. Also throwing (the umbrella) Exception is a bad practice. So, what should I do? Add a try catch block, and log and exit in the catch block? (Current approach) Create a custom exception class, wrap every exception and throw the custom exception? Add a throws declaration for all exceptions? Throw Exception?

    Read the article

  • How do I use the information about exceptions a method throws in .NET in my code?

    - by dotnetdev
    For many methods in .NET, the exceptions they can potentially throw can be as many as 7-8 (one or two methods in XmlDocument, Load() being one I think, can throw this many exceptions). Does this mean I have to write 8 catch blocks to catch all of these exceptions (it is best practise to catch an exception with a specific exception block and not just a general catch block of type Exception). How do I use this information? Thanks

    Read the article

  • Is Ogre's use of Exceptions a good way of using them?

    - by identitycrisisuk
    I've managed to get through my C++ game programming career so far virtually never touching exceptions but recently I've been working on a project with the Ogre engine and I'm trying to learn properly. I've found a lot of good questions and answers here on the general usage of C++ exceptions but I'd like to get some outside opinions from here on whether Ogre's usage is good and how best to work with them. To start with, quoting from Ogre's documentation of it's own Exception class: OGRE never uses return values to indicate errors. Instead, if an error occurs, an exception is thrown, and this is the object that encapsulates the detail of the problem. The application using OGRE should always ensure that the exceptions are caught, so all OGRE engine functions should occur within a try{} catch(Ogre::Exception& e) {} block. Really? Every single Ogre function could throw an exception and be wrapped in a try/catch block? At present this is handled in our usage of it by a try/catch in main that will show a message box with the exception description before exiting. This can be a bit awkward for debugging though as you don't get a stack trace, just the function that threw the error - more important is the function from our code that called the Ogre function. If it was an assert in Ogre code then it would go straight to the code in the debugger and I'd be able to find out what's going on much easier - I don't know if I'm missing something that would allow me to debug exceptions already? I'm starting to add a few more try/catch blocks in our code now, generally thinking about whether it matters if the Ogre function throws an exception. If it's something that will stop everything working then let the main try/catch handle it and exit the program. If it's not of great importance then catch it just after the function call and let the program continue. One recent example of this was building up a vector of the vertex/fragment program parameters for materials applied to an entity - if a material didn't have any parameters then it would throw an exception, which I caught and then ignored as it didn't need to add to my list of parameters. Does this seem like a reasonable way of dealing with things? Any specific advice for working with Ogre is much appreciated.

    Read the article

  • .NET and C# Exceptions. What is it reasonable to catch.

    - by djna
    Disclaimer, I'm from a Java background. I don't do much C#. There's a great deal of transfer between the two worlds, but of course there are differences and one is in the way Exceptions tend to be thought about. I recently answered a C# question suggesting that under some circstances it's reasonable to do this: try { some work } catch (Exeption e) { commonExceptionHandler(); } (The reasons why are immaterial). I got a response that I don't quite understand: until .NET 4.0, it's very bad to catch Exception. It means you catch various low-level fatal errors and so disguise bugs. It also means that in the event of some kind of corruption that triggers such an exception, any open finally blocks on the stack will be executed, so even if the callExceptionReporter fuunction tries to log and quit, it may not even get to that point (the finally blocks may throw again, or cause more corruption, or delete something important from the disk or database). May I'm more confused than I realise, but I don't agree with some of that. Please would other folks comment. I understand that there are many low level Exceptions we don't want to swallow. My commonExceptionHandler() function could reasonably rethrow those. This seems consistent with this answer to a related question. Which does say "Depending on your context it can be acceptable to use catch(...), providing the exception is re-thrown." So I conclude using catch (Exception ) is not always evil, silently swallowing certain exceptions is. The phrase "Until .NET 4 it is very bad to Catch Exception" What changes in .NET 4? IS this a reference to AggregateException, which may give us some new things to do with exceptions we catch, but I don't think changes the fundamental "don't swallow" rule. The next phrase really bothers be. Can this be right? It also means that in the event of some kind of corruption that triggers such an exception, any open finally blocks on the stack will be executed (the finally blocks may throw again, or cause more corruption, or delete something important from the disk or database) My understanding is that if some low level code had lowLevelMethod() { try { lowestLevelMethod(); } finally { some really important stuff } } and in my code I call lowLevel(); try { lowLevel() } catch (Exception e) { exception handling and maybe rethrowing } Whether or not I catch Exception this has no effect whatever on the excution of the finally block. By the time we leave lowLevelMethod() the finally has already run. If the finally is going to do any of the bad things, such as corrupt my disk, then it will do so. My catching the Exception made no difference. If It reaches my Exception block I need to do the right thing, but I can't be the cause of dmis-executing finallys

    Read the article

  • is there a proper way to handle multiple errors/exceptions?

    - by toPeerOrNotToPeer
    in OO programming, is there some conceptual pattern, ideas, about handling multiple errors? for example, i have a method that performs some checks and should return an error message for each error found ['name is too short', 'name contains invalid unicode sequences', 'name is too long'] now, should i use an array of exceptions (not thrown exceptions)? or something like this is better: class MyExceptionList extends Exception{ public Void addException(Exception e){} public Array getExceptions(){} } any theory behind this argument will be appreciated! (this isn't a request about a specific programming language, but a pure theoretical one) thank you in advance

    Read the article

  • One Exception to Aggregate Them All

    - by João Angelo
    .NET 4.0 introduced a new type of exception, the AggregateException which as the name implies allows to aggregate several exceptions inside a single throw-able exception instance. It is extensively used in the Task Parallel Library (TPL) and besides representing a simple collection of exceptions can also be used to represent a set of exceptions in a tree-like structure. Besides its InnerExceptions property which is a read-only collection of exceptions, the most relevant members of this new type are the methods Flatten and Handle. The former allows to flatten a tree hierarchy removing the need to recur while working with an aggregate exception. For example, if we would flatten the exception tree illustrated in the previous figure the result would be: The other method, Handle, accepts a predicate that is invoked for each aggregated exception and returns a boolean indicating if each exception is handled or not. If at least one exception goes unhandled then Handle throws a new AggregateException containing only the unhandled exceptions. The following code snippet illustrates this behavior and also another scenario where an aggregate exception proves useful – single threaded batch processing. static void Main() { try { ConvertAllToInt32("10", "x1x", "0", "II"); } catch (AggregateException errors) { // Contained exceptions are all FormatException // so Handle does not thrown any exception errors.Handle(e => e is FormatException); } try { ConvertAllToInt32("1", "1x", null, "-2", "#4"); } catch (AggregateException errors) { // Handle throws a new AggregateException containing // the exceptions for which the predicate failed. // In this case it will contain a single ArgumentNullException errors.Handle(e => e is FormatException); } } private static int[] ConvertAllToInt32(params string[] values) { var errors = new List<Exception>(); var integers = new List<int>(); foreach (var item in values) { try { integers.Add(Int32.Parse(item)); } catch (Exception e) { errors.Add(e); } } if (errors.Count > 0) throw new AggregateException(errors); return integers.ToArray(); }

    Read the article

  • What's the best practice to do SOA exception handling?

    - by sun1991
    Here's some interesting debate going on between me and my colleague when coming to handle SOA exceptions: On one side, I support what Juval Lowy said in Programming WCF Services 3rd Edition: As stated at the beginning of this chapter, it is a common illusion that clients care about errors or have anything meaningful to do when they occur. Any attempt to bake such capabilities into the client creates an inordinate degree of coupling between the client and the object, raising serious design questions. How could the client possibly know more about the error than the service, unless it is tightly coupled to it? What if the error originated several layers below the service—should the client be coupled to those lowlevel layers? Should the client try the call again? How often and how frequently? Should the client inform the user of the error? Is there a user? By having all service exceptions be indistinguishable from one another, WCF decouples the client from the service. The less the client knows about what happened on the service side, the more decoupled the interaction will be. On the other side, here's what my colleague suggest: I believe it’s simply incorrect, as it does not align with best practices in building a service oriented architecture and it ignores the general idea that there are problems that users are able to recover from, such as not keying a value correctly. If we considered only systems exceptions, perhaps this idea holds, but systems exceptions are only part of the exception domain. User recoverable exceptions are the other part of the domain and are likely to happen on a regular basis. I believe the correct way to build a service oriented architecture is to map user recoverable situations to checked exceptions, then to marshall each checked exception back to the client as a unique exception that client application programmers are able to handle appropriately. Marshall all runtime exceptions back to the client as a system exception, along with the stack trace so that it is easy to troubleshoot the root cause. I'd like to know what you think about this? Thank you.

    Read the article

  • What is best strategy to handle exceptions & errors in Rails?

    - by Nick Gorbikoff
    Hello. I was wondering if people would share their best practices / strategies on handling exceptions & errors. Now I'm not asking when to throw an exception ( it has been throroughly answered here: SO: When to throw and Exception) . And I'm not using this for my application flow - but there are legitimate exceptions that happen all the time. For example the most popular one would be ActiveRecordNotFound. What would be the best way to handle it? The DRY way? Right now I'm doing a lot of checking within my controller so if Post.find(5) returns Nil - I check for that and throw a flash message. However while this is very granular - it's a bit cumbersome in a sense that I need to check for exceptions like that in every controller, while most of them are essentially the same and have to do with record not found or related records not found - such as either Post.find(5) not found or if you are trying to display comments related to post that doesn't exist, that would throw an exception (something like Post.find(5).comments[0].created_at) I know you can do something like this in ApplicationController and overwrite it later in a particular controller/method to get more granular support, however would that be a proper way to do it? class ApplicationController < ActionController::Base rescue_from ActiveRecord::RecordInvalid do |exception| render :action => (exception.record.new_record? ? :new : :edit) end end

    Read the article

  • Dealing with Try/Catch Exceptions in Java bytecode? ("stack height inconsistent")

    - by Cogwirrel
    I am trying to do some error handling in java bytecode. I first tried to implement some catch-like subroutines, where I would check for the error condition, and jump to the appropriate subroutine, a little like: iconst_1 iconst_0 dup ifeq calldiverr goto enddivtest calldiverr: jsr divError enddivtest: idiv ...More instructions... divError: getstatic java/lang/System/out Ljava/io/PrintStream; ldc "Oh dear you divided by 0!" invokevirtual java/io/PrintStream/print(Ljava/lang/String;)V The problem with the above is that when I have multiple instructions that jump to this subroutine, I get an error message when running the bytecode, saying that the stack height is inconsistent. Perhaps using exceptions is the best way to get around this? From some googling I have found that you can create instances of Exception classes and initialise them with something like: new java/lang/Exception dup ldc "exception message!" invokespecial java/lang/Exception/<init>(Ljava/lang/String;)V I have also found that you can throw them with athrow and this seems ok. What is confusing me however is exactly how exceptions are caught. There seems to be a magical "Exception table" which glues the throwing and catching of exceptions together, but I do not know how to define one of these when writing bytecode from scratch (and assembling using Jasmin). Can somebody tell me the secret of creating an exception table? And possibly give me an example of exception handling that will assemble with jasmin?

    Read the article

  • How to structure code with 2 methods, one after another, which throw the same two exceptions?

    - by dotnetdev
    Hi, I have two methods, one called straight after another, which both throw the exact same 2 exceptions (IF an erroneous condition occurs, not stating that I'm getting exceptions). For this, should I write seperate try and catch blocks with the one statement in each try block and catch both exceptions (Both of which I can handle as I checked MSDN class library reference and there is something I can do, eg, re-open SqlConnection or run a query and not a stored proc which does not exist). So code like this: try { obj.Open(); } catch (SqlException) { // Take action here. } catch (InvalidOperationException) { // Take action here. } And likewise for the other method I call straight after. This seems like a very messy way of coding. The other way is to code with the exception variable (that is ommited as I am using AOP to log the exception details, using a class-level attribute). Doing this, this could aid me in finding out which method caused an exception and then taking action accordingly. Is this the best approach or is there another best practise altogether? I also assume that, as only these two methods are thrown, I do not need to catch Exception as that would be for an exception I cannot handle (causes way out of my control). Thanks

    Read the article

  • Always use dtexec.exe to test performance of your dataflows. No exceptions.

    - by jamiet
    Earlier this evening I posted a blog post entitled Investigation: Can different combinations of components effect Dataflow performance? where I compared the performance of three different dataflows all working to the same overall goal. I wanted to make one last point related to the results but I thought it warranted a blog post all of its own. Here is a screenshot of one of the dataflows that I was testing: Pretty complicated I’m sure you’ll agree. Now, when I executed this dataflow in the test it was executing in ~19seconds however in that case I was executing using the command-line tool dtexec. I also tried executing inside the BIDS development environment and in that case it took much longer – 139seconds. That’s more than seven times as long. The point I want to make is very simple. If you are testing your dataflows for performance please use dtexec. Nothing else will suffice. @Jamiet

    Read the article

  • Retour de fonctions ou exceptions ? Une traduction de LittleWhite

    Bonjour à tous, Lorsqu'une erreur se produit dans une fonction, un développeur C++ a deux solutions : il peut soit retourner une valeur indiquant une erreur (par exemple avec return false; ou return ERROR_CODE;), soit lancer une exception. Mais quelle est la meilleure approche ? Dans cet article, Aaron Lahman apporte des éléments de réponse à cette question cruciale en regardant les différences en terme de lisibilité et d...

    Read the article

  • Windows: what is the difference between DEP always on and DEP opt-out with no exceptions?

    - by Peter Mortensen
    What is the difference between DEP always on ("/NoExecute=AlwaysOn" in boot.ini) and DEP opt-out ( "/NoExecute=OptOut" in boot.ini) with no exceptions? "no exceptions" = empty list of programs for which DEP does not apply. DEP = Data Execution Prevention (hardware). One would expect it to work the same way, but it makes a difference for some applications. E.g. for all versions of UltraEdit 14 (14.2). It crashes at startup for DEP always on, at least on Microsoft Windows XP Professional Edition x64 edition. (2010-03-11: this problem has been fixed with UltraEdit 15.2 and later.) Update 1: I think this difference is caused by the backdoors that Microsoft has put into hardware DEP for OptOut, according to Fabrice Roux (see below). In the case of IrfanView, for which Steve Gibson observed the same difference as I did for UltraEdit (see below), the difference is caused by a non-DEP aware EXE packer (ASPack) that Microsoft coded a backdoor for. Is there a difference between Windows XP, Windows Vista and Windows 7 ? Is there a difference between 32 bit and 64 bit versions of Windows ? Sources: From [http://blog.fabriceroux.com/index.php/2007/02/26/hardware_dep_has_a_backdoor?blog=1], "Hardware DEP has a backdoor" by Fabrice Roux. 2007-02-26. "IrfanView was not using any trick to evade DEP ... Microsoft just coded a backdoor used only in OPTOUT. Bascially Microsoft checks the executable header for a section matching one of the 3 strings. If one these strings is found, DEP will be turned OFF for this application by windows. ... 'aspack', 'pcle', 'sforce'" From [http://www.grc.com/sn/sn-078.htm], by Steve Gibson. "I can’t find any documentation on Microsoft’s site anywhere, because we’re seeing a difference between always-on and opt-out. That is, you would imagine that always-on mode would be the same as opting out if you weren’t having any opt-out programs. It turns out it’s not the case. For example ... the IrfanView file viewer ... runs fine in opt-out mode, even if it has not been opted out. But it won’t launch, Windows blocks it from launching ... in always-on mode." From [http://www.grc.com/sn/sn-083.htm], by Steve Gibson. "... IrfanView ... won’t run with DEP turned on. It’s because it uses an EXE packer, an executable compression program called ASPack. And it makes sense that it wouldn’t because naturally an executable compressor has got to decompress the executable, so it allocates a bunch of data memory into which it decompresses the compressed executable, and then it runs it. Well, it’s running a data allocation, which is exactly what DEP is designed to stop. On the other hand, UPX, which is actually the leading and most popular EXE compressor, it’s DEP- compatible because those guys realized, hey, when we allocate this memory, we should mark the pages as executable."

    Read the article

  • Having all Views in the Shared folder - works but is throwing "caught exceptions". Performance conc

    - by Scott
    Hi everyone, I have a simple but heavily used app done in VS2010/MVC2. I didn't like having separate folders for each view/controller and so have all the views in the Shared folder. It's working fine but while debugging in VS, I noticed that it's throwing IO "caught exceptions" since it seems to be looking in the [FolderName]/[ViewName] folder before going down to the Shared folder. Again, the app runs fine but I'm concerned that all these "caught exceptions" will have a minor performance impact since they do have a cost in via the CLR. Is there any way I can configure the Routing so that it will only look in the Shared folder? Thanks.

    Read the article

  • How to catch exceptions from another program (for logging)?

    - by CuriousCoder
    I am working on a tool that monitors a number of applications and ensures they are always running and in a clean state. Some of these applications have unhandled exceptions which do occur periodically and present the 'send crash report' window. I do not have the source code to these applications. Is there any mechanism I could use to catch the exceptions, or simply identify their exception type, as well as identify the application's main executable file that threw the exception. I'm not trying to do anything crazy like catch and handle it on the applications behalf, I'm simply trying to capture the exception type, log it and then restart the application.

    Read the article

  • Is there a file diff tool that allows for exceptions?

    - by Kevin
    We currently use Beyond Compare 3.0 and I am quite pleased with it. However, it would be great if I could easily specify an exclusion for a specific one-time case. This is needed when I am doing a code review of some refactoring. For instance: Old code doSomething(ConstantsInterface.FOOBAR); New code: doSomething(BetterEnumeration.FOOBAR); In this case, I have hundreds of changes that I am reviewing that are essentially all the same exact change and I just want to see the exceptions. It would be great if I could easily specify an exception that indicates these two cases are equal. I know of a way to do it in the grammar, but it is tedious and cumbersome in the case where there are ten or so exceptions. Any other tips?

    Read the article

  • ' send fail ' when server resource is unavailable-how can we handle such exceptions in flex ?

    - by developer
    ' send fail ' when server resource is unavailable-how can we handle such exceptions in flex ? i designed Air Application which pulls data from Jetty server, at a time of loading application, but here is a exception is ...am getting 'Send Fail' when server resource is not available & [RPC Fault faultString="Send failed" faultCode="Client.Error.MessageSend" faultDetail="Channel.Connect.Failed error NetConnection.Call.Failed: HTTP: Failed: url: 'http://ip"port/myapp/My-amf... how can i handle exceptions like when server is off, when server is on but DB server is not available ? please help me , thanks in advance

    Read the article

  • Can somebody explain the difference between exceptions and errors (specific to PHP)?

    - by letseatfood
    I am having trouble figuring the best way to display errors to my clients. Should I use exceptions or errors? For example, if the user's login information does not match the database, should I throw new Exception('Login information is incorrect. Please try again.') and catch it with an exception handler using set_exception_handler()? Or, should I use trigger_error() to display an error message to the user? I think the main issue is that I cannot differentiate between errors and exceptions. I have read a lot of "answers" to this question on the internet and in some books, but it seems that people are really divided or aren't sure. Thanks!

    Read the article

  • Where should I handle the exceptions, in the BLL, DAL or PL ?

    - by Puneet Dudeja
    Which is the best place to handle the exceptions ? BLL, DAL or PL ? Should I allow the methods in the DAL and BLL to throw the exceptions up the chain and let the PL handle them? or should I handle them at the BLL ? e.g If I have a method in my DAL that issues "ExecuteNonQuery" and updates some records, and due to one or more reason, 0 rows are affected. Now, how should I let my PL know that whether an exception happened or there really was no rows matched to the condition. Should I use "try catch" in my PL code and let it know through an exception, or should I handle the exception at DAL and return some special code like (-1) to let the PL differentiate between the (exception) and (no rows matched condition i.e. zero rows affected) ?

    Read the article

  • How do you handle exceptions from API/library in your code?

    - by 5YrsLaterDBA
    I have the following lines of code: FileInfo dbFile = new FileInfo(fileName); dbFileSize = (long)dbFile.Length / 1024;//KB There are 8 possible exceptions from new FileInfo(fileName) and dbFile.Length calls. I cannot just ignore them. I have to catch them. What you are going to do with those 8 exceptions? Catch them separately (too many lines)? Catch only ONE by catching the super Exception excepton? or ...

    Read the article

  • Using the JRockit Flight Recorder as an Exception Profiler.

    - by Marcus Hirt
    There is a lot of new data points in the JRockit Flight Recorder compared to the data available in the old JRA. One set of data deals with exceptions and where they are thrown. In JRA, it was possible to tell how many exceptions were thrown, but it was not possible to determine from where they were thrown. Here is how to do a recording with exception profiling enabled from JRockit Mission Control. 1. Right click on the JVM to profile, select Start Flight Recording. 2. Select the Profiling with Exceptions template.   3. Wait for the recording to finish. The count down for the time left will show in the Flight Recorder Control view. 4. When done the recording will automatically be downloaded and displayed. To show the exceptions, go to the Code | Exceptions tab.

    Read the article

< Previous Page | 13 14 15 16 17 18 19 20 21 22 23 24  | Next Page >